Данное издание относится к:
и ко всем последующим выпускам и модификациям, если в последующих изданиях не будет указано обратное.
Заказать документацию можно у местного представителя фирмы IBM или в местном филиале IBM.
Данное руководство, Концепции, планирование и установка WebSphere Application Server для Edge Components, является введением в WebSphere Application Server Edge components. Оно содержит обзоры продукта, подробное описание функциональности ключевых компонентов, сетевые сценарии, сведения об установке и первичной настройке и примеры сетей.
Концепции, планирование и установка WebSphere Application Server для Edge Components предназначено для опытных сетевых и системных администраторов, знакомых с применяемыми операционными системами и с предоставлением Internet-услуг. Опыт работы с WebSphere Application Server или WebSphere Application Server Edge components не обязателен.
Специальные возможности облегчают работу с программными продуктами пользователям с ограниченными физическими способностями, например, с ослабленным зрением или с ограниченными возможностями передвижения. Ниже перечислены основные специальные возможности WebSphere Application Server, Версия 6.1:
В данной документации используются следующие типографические и ключевые соглашения.
Соглашение | Значение |
---|---|
Жирный | В отношении графических интерфейсов пользователя (GUI) жирным шрифтом выделяются меню, элементы меню, метки, кнопки, значки и папки. Он также используется для выделения имен команд, чтобы отличить их от окружающего текста. |
Непропорциональный шрифт | Указывает текст для ввода в командной строке. Непропорциональным шрифтом также выделяется экранный текст, примеры кода и фрагменты файлов. |
Курсив | Используется для указания различных вводимых значений (например, вы вводите имя файла для fileName). Курсивом также выделяются названия книг и он служит для выделения фрагментов текста. |
Ctrl-x | Где x названием клавиши, указывает последовательность управляющих символов. Например, Ctrl-c означает нажатие клавиши "c" при нажатой клавише Ctrl. |
Возврат | Клавиша возврата с указанным на ней словом Return, Enter или изогнутой стрелкой влево. |
% | Представляет командную строку Linux и UNIX для команды, не требующей прав доступа root. |
# | Представляет командную строку Linux и UNIX для команды, требующей права доступа root. |
C:\ | Представляет командную строку Windows. |
Ввод команд | Когда требуется "ввести" или "выполнить" команду, укажите команду и нажмите клавишу Возврат. Например, инструкция "Введите команду ls" означает, что требуется напечатать в командной строке ls и нажать клавишу Возврат. |
[ ] | Содержит необязательные элементы синтаксического описания. |
{ } | Содержит списки из которых следует выбрать элемент синтаксического описания. |
| | Разделяет элементы в списке, заключенном в скобки { } в синтаксическом описании. |
... | Многоточие в синтаксическом описании указывает на возможность повтора предыдущего элемента один или несколько раз. Многоточие в примерах указывает, что некоторая информация в примере была пропущена во имя краткости. |
В данной части содержатся общие сведения о WebSphere Application Server Edge components, Caching Proxy и Load Balancer и описание их интеграции с Application Server. Также приведены описания Caching Proxy и Load Balancer. Кроме того в данном разделе содержатся сведения и о других продуктах семейства WebSphere.
Данная часть содержит следующие главы:
WebSphere является программным обеспечением инфраструктуры Internet, позволяющим компаниям разрабатывать, развертывать и интегрировать приложения электронного бизнеса следующего поколения, например, электронной коммерции бизнес-бизнес. Промежуточное программное обеспечение WebSphere поддерживает бизнес-приложения, от простой Web-публикации до обработки транзакций уровня предприятия.
Будучи основанием платформы WebSphere, WebSphere Application Server обладает исчерпывающим набором промежуточного программного обеспечения, позволяющим пользователю разрабатывать, применять, развертывать и управлять бизнес-приложениями. Эти приложения варьируются от предназначенных для создания простых Web-сайтов до выполнения полной ревизии компьютерной инфраструктуры организации.
Требующие большой вычислительной мощи функции, такие как персонализация, предлагают конкурентное преимущество каждому электронному бизнесу. Однако, передача этих функций центральным серверам может предотвратить масштабирование важных функций до масштаба Internet. Следовательно, при постоянном добавлении новых Web-приложений, бизнес-инфраструктура Internet должна увеличиваться в размере и влиянии. Кроме того, для электронного бизнеса очень важны вопросы надежности и защиты. Даже незначительный перебой в работе может привести к потере бизнеса.
Edge components (ранее Edge Server) теперь является частью WebSphere Application Server. Edge components можно использовать совместно с WebSphere Application Server для управления доступом клиентов к Web-серверам и обеспечения более качественного обслуживания пользователям, обращающимся к Web-информационному наполнению через Internet или корпоративную сеть. С помощью Edge components можно снизить перегрузку Web-сервера, повысить доступность информационного наполнения и улучшить производительность Web-сервера. Как следует из названия, Edge components обычно выполняется в системах, близко расположенных (с точки зрения конфигурации сети) к границе между корпоративной сетью и Internet.
WebSphere Application Server включает в себя Caching Proxy и Load Balancer Edge Components.
ВАЖНАЯ ИНФОРМАЦИЯ: Caching Proxy доступен во всех версиях Edge Components исключая следующее:
Caching Proxy снижает загруженность сети и повышает скорость работы и надежность Web-сайта, предоставляя узел точки присутствия для одного или нескольких базовых серверов информационного наполнения. Caching Proxy может кэшировать и обслуживать как статичное информационное наполнение, так и информационное наполнение, динамически создаваемое WebSphere Application Server.
Caching Proxy может быть настроен для выполнения роли обратного сервера caching proxy (конфигурация по умолчанию) или пересылающего сервера caching proxy, предоставляющего или точку присутствия (point-of-presence) для сети, или внутренний сетевой сервер, предназначенный для оптимизации запросов и времени ответов. Более подробная информация об обратной и пересылающей конфигурации находится в разделе Основная конфигурация Caching Proxy.
сервер proxy перехватывает запросы к данным от клиента, извлекает запрошенную информацию из хостов информационного наполнения и передает информационное наполнение обратно клиенту. Наиболее часто поступают запросы на документы, хранящиеся в системах Web-серверов (которые также называются исходными серверами или хостами информационного наполнения) и публикуемых с помощью протокола передачи гипертекстовой информации (HTTP). Однако, можно настроить сервер proxy для обработки и других протоколов, например протокола передачи файлов (FTP) и Gopher.
сервер proxy сохраняет кэшируемое информационное наполнение в локальном кэше перед его отправкой инициатору запроса. Примерами кэщируемого информационного наполнения могут служить статичные Web-страницы и файлы JavaServer Pages, содержащие динамически создаваемую, но редко меняемую, информацию. Кэширование позволяет сервер proxy удовлетворить последующие запросы на доступ к тому же информационному наполнению, извлекая его непосредственно из локального кэша, что намного быстрее, чем повторное его извлечение из хоста информационного наполнения.
Встраиваемые модули для Caching Proxy добавляют сервер proxy дополнительную функциональность.
Можно еще более расширить функциональность Caching Proxy с помощью пользовательских встраиваемых модулей для интерфейса программирования приложения (API). API является гибким, простым в использовании и независимым от платформы. Proxy выполняет последовательность действий для каждого обрабатываемого клиентского запроса. Встраиваемый модуль изменяет или замещает одно из действий в потоке обработки запроса, например, идентификацию клиента или фильтрацию запроса. Например, мощный интерфейс Transmogrify предоставляет доступ к данным HTTP и допускает замещение или трансформацию URL и Web- информационного наполнения. Встраиваемые модули могут изменять или замещать обычные этапы обработки и могут вызывать несколько модулей для выполнения определенного этапа.
Load Balancer создает пограничные сетевые системы, регулирующие поток сетевых данных, снижающих перегрузку и распределяющих нагрузку на различные службы и системы. Load Balancer обеспечивает отбор сайтов, управление нагрузкой, привязку сеансов и прозрачное переключение.
Load Balancer устанавливается между Internet и основными серверами организации, которыми могут быть хосты информационного наполнения или системы Caching Proxy. Load Balancer выполняет роль единой точки присутствия компании в Internet, даже если компания использует несколько базовых серверов из-за высокой нагрузки или большого объема информационного наполнения. Можно гарантировать высокую готовность, установив резервную копию Load Balancer на случай, если основная копия временно выйдет из строя.
Load Balancer перехватывает запросы к данным, поступающие от клиента, и пересылает каждый запрос к серверу, который в данный момент является оптимальным для обработки запроса. Иными словами, выполняется распределение входящих запросов внутри заданного набора систем, обслуживающих один тип запросов. Load Balancer может распространять запросы между многими типами серверов, включая системы WebSphere Application Server и Caching Proxy. Распределение нагрузки можно настроить для определенного приложения или платформы с помощью пользовательских советников. Для получения информации о распределении нагрузки для WebSphere Application Server доступны советники специального назначения.
Если компонент Content Based Routing установлен вместе с Caching Proxy, запросы HTTP и HTTPS могут быть распределены исходя из URL или других определяемых администратором характеристик, что позволяет отказаться от необходимости хранить идентичное информационное наполнение на всех базовых серверах. Компонент Dispatcher может также обеспечить такую же функциональность для запросов HTTP.
Распределение нагрузки повышает готовность и масштабируемость Web-сайта за счет прозрачного распределения по кластерам серверов информационного наполнения, включая серверы HTTP, серверы приложений и серверы proxy, являющиеся суррогатными серверами с одержимого. Готовность обеспечивается за счет параллелизма, распределения нагрузки и поддержки переключения. Когда сервер недоступен, бизнес не прерывается. Масштабируемость инфраструктуры можно существенно повысить за счет прозрачного добавления базовой вычислительной мощности.
Поддержка IPv6: Поддержка расширенной схемы IP-адресации IPv6 обеспечивается "Load Balancer for IPv4 and IPv6". Load Balancer for IPv4 and IPv6 является отдельным установочным образом, состоящим только из компонента Dispatcher. Этот тип установки обеспечивает распределение нагрузки для потока данных IPv4 и IPv6 для серверов, настроенных внутри сети с помощью пересылки пакетов на основе MAC Dispatcher. Важно отметить, что предыдущие версии Load Balancer следует удалить из системы перед установкой Load Balancer for IPv4 and IPv6. В одной системе нельзя установить для разных Load Balancer. (Краткое описание компонента Dispatcher содержится в Dispatcher).
Load Balancer содержит следующие компоненты:
Для всех Internet-служб, таких как HTTP, FTP, HTTPS и Telnet, компонент Dispatcher выполняет распределение нагрузки для серверов внутри локальной сети (LAN) или глобальной сети (WAN). Для служб HTTP Dispatcher может выполнять распределение нагрузки для серверов, на основе информационного наполнения URL клиентского запроса.
Компонент Dispatcher обеспечивает стабильное, эффективное управление крупными масштабируемыми сетями серверов. С помощью Dispatcher можно соединить несколько отдельных серверов в единый виртуальный сервер. Таким образом, ваш сайт будет виден остальному миру под одним IP-адресом.
При использовании установки Load Balancer for IPv4 and IPv6 см. главу о развертывании Dispatcher в Load Balancer for IPv4 and IPv6 в Руководство по управлению WebSphere Application Server Load Balancer, содержащую сведения об ограничениях и различиях настройки.
Для служб HTTP и HTTPS компонент Content Based Routing выполняет распределение нагрузки для серверов исходя из информационного наполнения клиентского запроса. Компонент Content Based Routing работает совместно с компонентом Application Server Caching Proxy.
ВАЖНАЯ ИНФОРМАЦИЯ: Компонент CBR Content Based Routing доступен во всех поддерживаемых платформах исключая следующее:
В качестве альтернативы для данного типа установки можно использовать способе пересылки CBR компонента Load Balancer' Dispatcher для обеспечения маршрутизации на основе информационного наполнения запросов HTTP и HTTPS без использования Caching Proxy. Дополнительные сведения содержатся в WebSphere Application Server Load Balancer Administration Guide.
Load Balancer for IPv4 and IPv6 поддерживает только способ пересылки MAC компонента. Пересылка nat и cbr не поддерживается.
Компонент Site Selector позволяет расширить систему распределения нагрузки, позволяя ей выполнять роль узла единой точки присутствия в сети и распределять входящие запросы с помощью привязки имен DNS к IP-адресам. Совместно с Metric Server, Site Selector может отслеживать активность сервера, определять минимальную загрузку сервера и обнаруживать сбои сервера.
Данный компонент поддерживается во всех версиях Edge Components исключая следующее:
Компонент Cisco CSS Controller создает показатели веса сервера, посылаемые переключателю Cisco CSS для выбора сервера, оптимизации нагрузки и устойчивости к сбоям.
Данный компонент поддерживается во всех версиях Edge Components исключая следующее:
Компонент Nortel Alteon Controller создает показатели веса сервера, посылаемые переключателю Nortel Alteon для выбора сервера, оптимизации нагрузки и устойчивости к сбоям.
Данный компонент поддерживается во всех версиях Edge Components исключая следующее:
Компонент Metric Server выполняет роль демона на сервере распределения нагрузки и предоставляет сведения о нагрузке на систему компонента Load Balancer.
Семейство IBM WebSphere призвано помочь пользователям реализовать преимущества электронного бизнеса. Это набор программных продуктов, облегчающий разработку и управление высокопроизводительными Web-сайтами и интеграцию Web-сайтов с новыми или имеющимися не-Web информационными бизнес-системами.
Семейство WebSphere состоит из WebSphere Application Server, включая программное обеспечение Edge components и других семейств WebSphere, тесно интегрированных с WebSphere Application Server и повышает его производительность. Обзор WebSphere Application Server и его компонентов содержится в Введение в WebSphere Application Server Edge components.
Tivoli Access Manager (ранее Tivoli Policy Director) поставляется отдельно. Он предоставляет права доступа и централизованную защиту для имеющихся Web-приложений и предлагает возможность разовых проверок прав доступа с доступом к нескольким Web-ресурсам. Компонент Caching Proxy использует систему защиты Диспетчера управления доступом, позволяя сервер proxy использовать интегрированные службы идентификации или проверки прав доступа диспетчера управления доступом.
WebSphere Portal Server (поставляется отдельно) предлагает систему для выполнения задач презентации, защиты, масштабируемости и готовности, связанных с порталами. С помощью Portal Server компании могут создавать собственные пользовательские Web-сайты портала для обслуживания сотрудников, бизнес-партнеров и заказчиков. Пользователи могут заходить на портал и просматривать персонализированные Web-страницы, обеспечивающие доступ к нужным информации, приложениями и сотрудниками. Эта персонализированная единая точка доступа ко всем нужным ресурсам снижает нагрузку, повышает производительность и улучшает эффективность применения Web-сайта.
WebSphere Portal Server выполняется в кластере WebSphere Application Server для достижения масштабируемости и надежности. Компонент Application Server Load Balancer можно также использовать для обеспечения дополнительного распределения нагрузки и высокой готовности.
WebSphere Site Analyzer (поставляется отдельно) помогает предприятиям предвидеть потенциальные нехватки емкости и производительности. С помощью Site Analyzer можно использовать протоколы и прочие вспомогательные средства Caching Proxy и Load Balancer для прогнозирования возникновения необходимости добавления дополнительных ресурсов, за счет мониторинга, анализа и составления отчетов об использовании вашего Web-сайта. Кроме того, компоненты Site Analyzer призваны помочь пользователям в установке и обновлении Edge components, управлении и хранении конфигураций, удаленной работе с Edge components и просмотре и составлении отчетов о событиях.
WebSphere Transcoding Publisher (поставляется отдельно) может преобразовывать Web-страницы для просмотра с помощью мобильных устройств, например, мобильных телефонов с выходом в Internet, переводить информационное наполнение Web-страниц на другой я зык (посредством вызова WebSphere Translation Server), и преобразовывать языки разметки. Transcoding Publisher расширяет возможности Caching Proxy, позволяя ему передавать информацию различным устройствам и пользователям. Можно настроить интерфейс Caching Proxy Transmogrify для вызова Transcoding Publisher после обращения к информационному наполнению Web-сервера для преобразования данных и добавления тегов для возможного последующего использования и кэширования. Затем в интерфейс Caching Proxy после идентификации Transcoding Publisher проверяет сервер proxy на совпадение информационного наполнения с требованиями пользователя и устройства и при обнаружении совпадений поставляет информационное наполнение из кэша сервер proxy.
В справочной системе Edge Components Information Center доступна следующая документация по WebSphere Application Server Edge Components.
Дополнительная документация по WebSphere Application Server доступна на странице библиотеки WebSphere Application Server.
Документация по технической поддержке Edge Components доступна со страницы поддержки WebSphere Application Server.
Ниже приведен список Web-сайтов, содержащих информацию о Edge Components или другие связанные сведения:
Данная часть содержит подробные описания и сведения о некоторых функциях компонентов Edge. В Введение в WebSphere Application Server Edge components приведен обзор компонента Application Server Caching Proxy.
Данная часть содержит следующие главы:
Маршрутизация на основе информационного наполнения
Функция кэширования Caching Proxy позволяет минимизировать нагрузку на пропускную способность сети и обеспечивает более быстрое и надежное обслуживание пользователей. Это возможно благодаря снижению нагрузки на базовые серверы и ссылки, за счет кэширования, выполняемого сервер proxy. Caching Proxy может кэшировать как статичное информационное наполнение, так и информационное наполнение, динамически создаваемое WebSphere Application Server. Для поддержки расширенного кэширования Caching Proxy также использует компонент Application Server Load Balancer. Общие сведения об этих системах содержатся в разделе Введение в WebSphere Application Server Edge components.
ВАЖНАЯ ИНФОРМАЦИЯ: Caching Proxy доступен во всех версиях Edge Components исключая следующее:
Caching Proxy может быть настроен для выполнения роли обратного сервера caching proxy (конфигурация по умолчанию) или пересылающего сервера caching proxy. При использовании хостами информационного наполнения Caching Proxy настраивается для выполнения роли обратного сервера caching proxy, расположенного между Интернет и хостами информационного наполнения предприятия. При использовании провайдерами доступа к Интернет Caching Proxy настраивается для выполнения роли пересылающего сервера caching proxy, расположенного между клиентом и Интернет.
При использовании конфигурации обратного proxy системы Caching Proxy расположены между сетью Интернет и хостами информационного наполнения. Выполняя роль суррогата, сервер proxy перехватывает запросы, поступающие из сети Internet, перенаправляет их в соответствующие хосты информационного наполнения, кэширует возвращаемые данные и переправляет их пользователям через Internet. Кэширование позволяет Caching Proxy удовлетворить последующие запросы на доступ к тому же информационному наполнению непосредственно из кэша, что намного быстрее, чем повторное извлечение данных из хоста информационного наполнения. Информация может кэшироваться исходя из срока хранения, объема кэша и времени обновления данных. Более быстрая загрузка данных из кэша означает более качественное обслуживание клиентов. В разделе Рис. 1 описываются основные функции Caching Proxy.
Условные обозначения: 1--Клиент 2--Интернет 3--Маршрутизатор/Шлюз 4--Caching Proxy 5--Кэш 6--Хост информационного наполненияВ данной конфигурации сервер proxy (4) перехватывает запросы, URL которых содержит имя хоста информационного наполнения (6). Когда клиент (1) запрашивает файл X, запрос переправляется по сети Internet (2) и попадает в внутреннюю корпоративную сеть через шлюз Internet (3). сервер proxy перехватывает запрос, создает новый запрос с собственным IP-адресом в качестве исходящего адреса и отправляет новый запрос в хост информационного наполнения (6).
Хост информационного наполнения возвращает файл X в сервер proxy, вместо того, чтобы напрямую передавать его конечному пользователю. Если файл предназначен для кэширования, Caching Proxy сохраняет копию в кэше (5) перед передачей его конечному пользователю. Наиболее распространенным примером доступного для кэширования информационного наполнения являются статические Web-страницы; тем не менее Caching Proxy также поддерживает возможность обслуживания и кэширования информационного наполнения, динамически создаваемого WebSphere Application Server.
Предоставление конечным пользователям прямого доступа к Интернет может быть очень неэффективным. Каждый пользователь, который загружает данный файл с Web-серверов, генерирует такой же поток данных в сети и через шлюз Интернет, как и первый пользователь, загрузивший этот файл, даже если файл не изменен. Решение состоит в том, чтобы установить пересылающий Caching Proxy перед шлюзом.
При использовании конфигурации пересылающего proxy системы Caching Proxy расположены между сетью Интернет и клиентом. Caching Proxy пересылает запрос клиента хосту информационного наполнения, расположенному в Интернет, кэширует полученные данные и доставляет их клиенту.
Рис. 2 иллюстрирует конфигурацию пересылающего Caching Proxy. Клиентские браузеры (в системах, обозначенных 1) настроены на прямые запросы к пересылающему caching proxy (2), который настроен на перехват запросов. Когда пользователь запрашивает файл X, хранящийся на хосте информационного наполнения (6), пересылающий caching proxy перехватывает запрос, создает новый запрос с собственным IP-адресом в качестве исходящего адреса и отправляет новый запрос средствами маршрутизатора предприятия (4) в Интернет (5).
Таким образом, исходный сервер возвращает файл X пересылающему caching proxy, а не конечному пользователю. Если включена функция кэширования пересылающего Caching Proxy, то он определяет возможность кэширования файла X, проверяя параметры в его заголовке возврата, такие как дата истечения срока или пометку о динамическом создании файла. Если файл доступен для кэширования, Caching Proxy сохраняет его копию в кэше (3) перед его передачей конечному пользователю. По умолчанию кэширование включено и пересылающий Caching Proxy использует кэш памяти. Однако, можно настроить другие типы кэширования.
Для первого запроса файла X пересылающий Caching Proxy не улучшает эффективность доступа к Интернет. На самом деле, время ответа для первого запроса файла X может оказаться большим, чем без пересылающего Caching Proxy, потому что пересылающий Caching Proxy тратит некоторое время на обработку пакета первоначального запроса и проверку заголовка файла X на возможность кэширования при его получении. Использование пересылающего Caching Proxy оправдывается, когда впоследствии другие пользователи запрашивают файл X. Пересылающий Caching Proxy проверяет, верна ли еще его кэшированная копия файла X (не истек ли срок годности), и если это так, возвращает файл X прямо из кэша, без пересылки запроса по Интернет хосту информационного наполнения.
Даже если пересылающий Caching Proxy обнаружит, что файл просрочен, он не обязательно должен повторно загружать файл с хоста информационного наполнения. Вместо этого, он посылает хосту информационного наполнения специальное сообщение проверки состояния. Если хост информационного наполнения подтвердит, что файл не изменен, то пересылающий Caching Proxy может вернуть пользователю кэшированную версию.
Конфигурация пересылающего Caching Proxy называется так потому, что Caching Proxy действует от имени браузеров, перенаправляя их запросы хостам информационного наполнения через Интернет. Использование пересылающего caching proxy имеет два преимущества:
Caching Proxy может работать с несколькими сетевыми протоколами, включая HTTP (Протокол передачи гипертекста), FTP (Протокол передачи файлов) и Gopher.
Одной из видов пересылающего Caching Proxy является прозрачный Caching Proxy. В это роли Caching Proxy выполняет те же функции, что и основной пересылающий Caching Proxy, но он делает это незаметно для пользователя. Конфигурация прозрачного Caching Proxy поддерживается только в системах Linux.
В конфигурации, описанной в Пересылающий Caching Proxy, каждый клиентский браузер отдельно настраивается на прямые запросы к определенному пересылающему Caching Proxy. Управление такой конфигурацией может стать неудобным, особенно для большого числа клиентов. Caching Proxy поддерживает несколько альтернативных вариантов для упрощения администрирования. Одна из возможностей состоит в том, чтобы настроить Caching Proxy в качестве прозрачного proxy, как это показано на рисунке Рис. 3. Так же как и для обычного пересылающего Caching Proxy, прозрачный Caching Proxy устанавливается в системе перед шлюзом, но клиентские браузеры не настраиваются на прямые запросы к пересылающему Caching Proxy. В этой конфигурации клиенты не знают о существовании proxy. Вместо этого, маршрутизатор настраивается на перехват клиентских запросов и пересылку их прозрачному Caching Proxy. Когда клиент работает в одной из систем, помеченных 1, запросы файла X, хранящегося на хосте информационного наполнения (6), передаются маршрутизатором (2) на Caching Proxy. Caching Proxy создает новый запрос с собственным IP-адресом в качестве исходящего адреса и отправляет новый запрос средствами маршрутизатора (2) в Интернет (5). При получении файла X Caching Proxy кэширует его, если требуется (условия описаны в разделе Пересылающий Caching Proxy), и передает файл запрашивающему клиенту.
Для запросов HTTP есть еще один вариант управления конфигурацией proxy на каждом браузере. Он состоит в том, чтобы использовать функцию автоматической конфигурации proxy, доступную в некоторых браузерах, включая Netscape Navigator версии 2.0 и выше и Microsoft Internet Explorer версии 4.0 и выше. В этом случае, вы создаете один или несколько файлов центральной автоматической конфигурации proxy (PAC) и настраиваете браузеры на один из них, а не на локальную конфигурацию proxy. Браузеры будут автоматически учитывать все изменения в PAC и соответственно приспосабливать свое использование proxy. Это не только избавляет от необходимости управления отдельными конфигурациями в каждом браузере, но также упрощает перенаправление запросов в случае недоступности сервера proxy.
Третья альтернатива состоит в использовании механизма Web Proxy Auto Discovery (WPAD), доступного в некоторых браузерах, таких как Internet Explorer версии 5.0 и выше. При включении этой функции в браузере она автоматически находит в сети совместимый с WPAD сервер proxy и перенаправляет запросы Web туда. В этом случае не нужно управлять файлами центральной конфигурации proxy. Caching Proxy совместим с WPAD.
Для поддержки функций расширенного кэширования используйте Caching Proxy в качестве обратного Proxy вместе с компонентом Load Balancer. Благодаря интеграции кэширования и распределения нагрузки можно создать эффективную управляемую производительную Web-инфраструктуру.
В разделе Рис. 4 описана процедура совместного применения Caching Proxy и Load Balancer для эффективной доставки Web-информационного наполнения даже при чрезвычайно высоком спросе. В данной конфигурации сервер proxy (4) настроена для перехвата запросов, URL которых содержат имя хоста кластера хостов информационного наполнения (7) с распределением нагрузки, выполненной Load Balancer (6).
Условные обозначения: 1--Клиент 2--Internet 3--Маршрутизатор/Шлюз 4--Caching Proxy 5--Кэш 6--Load Balancer 7--Хост информационного наполненияКогда клиент (1) запрашивает файл X, запрос переправляется по сети Internet (2) и попадает в внутреннюю корпоративную сеть через шлюз Internet (3). сервер proxy перехватывает запрос, создает новый запрос с собственным IP-адресом в качестве исходящего адреса и отправляет новый запрос в Load Balancer по адресу кластера. Load Balancer использует алгоритм распределения нагрузки чтобы определить, какой хост информационного наполнения в данный момент оптимально подходит для обработки запроса файла X. Этот хост информационного наполнения возвращает файл X в сервер proxy, а не через Load Balancer. сервер proxy определяет, кэшировать ли его и переправляет конечному пользователю так же, как описано выше.
Функция расширенного кэширования также поддерживается компонентом динамического кэширования Caching Proxy. При использовании совместно с WebSphere Application Server, Caching Proxy позволяет кэшировать, обслуживать и аннулировать динамическое информационное наполнение в форме откликов JavaServer Pages (JSP) и сервлетов, создаваемых WebSphere Application Server.
Обычно динамическое информационное наполнение с неограниченным сроком действия должно помечать "без кэширования", так как стандартная логика удаления данных из кэша по истечении срока хранения не обеспечивает своевременное удаление таких данных. Логика времени истечения срока хранения событий компонента динамического кэширования позволяет кэшировать информационное наполнение с неограниченным сроком хранения с помощью сервер proxy. Кэширование этой информации освобождает хосты информационного наполнения от повторяющихся вызовов Application Server для обслуживания запросов клиентов. Это обеспечивает следующие преимущества:
Кэширование ответа сервлета идеально подходит для динамических Web-страниц, устаревающих согласно логике приложения или при возникновении события, например, при получении сообщения из базы данных. Несмотря на то, что срок хранения такой страницы ограничен, значение времени хранения в кэше нельзя задать во время создания, так как триггер истечения срока хранения заранее неизвестен. Когда значение времени хранения в кэше для таких страниц равен нулю, хосты информационного наполнения подвергаются значительной нагрузке при обслуживании динамического информационного наполнения.
Ответственность за синхронизацию динамического кэша Caching Proxy и Application Server поделена между обеими системами. Например, внешняя Web-страница с прогнозом погоды, динамически созданная приложением, может быть экспортирована Application Server и кэширована Caching Proxy. Затем Caching Proxy может повторно поставлять результаты выполнения приложения нескольким различным пользователям до получения уведомления о недопустимой странице. Содержимое ответа сервлета Caching Proxy является допустимым до тех пор пока сервер proxy не удалит запись из-за перегрузки кэша, не закончится тайм-аут по умолчанию, заданный директивой ExternalCacheManager в файле конфигурации Caching Proxy или Caching Proxy не получит сообщение Аннулировать с инструкцией очистить информационное наполнение кэша. Сообщения об аннулировании поступают от WebSphere Application Server, владеющего информационным наполнением, и предназначаются всем настроенным Caching Proxy.
Caching Proxy предлагает и другие ключевые дополнительные функции кэширования:
Сетевое быстродействие зависит от функциональнсти Caching Proxy. Для повышения быстродействия сети используйте Caching Proxy отдельно или совместно с Load Balancer. Общие сведения об этих системах содержатся в разделе Введение в WebSphere Application Server Edge components.
Быстродействие Caching Proxy на вашем предприятии зависит от используемого аппаратного обеспечения и общей архитектуры системы, в которой выполнена установка. Для оптимизации быстродействия сети, измените аппаратное обеспечение и общую сетевую архитектуру согласно характеристикам сервер proxy.
Базовая настройка и администрирование программного обеспечения Caching Proxy и настройка операционной системы также существенно влияет на быстродействие Caching Proxy. Для повышения быстродействия можно внести определенные изменения в настройку; например, настроить параметры ведения протоколов, правила преобразования,встраиваемые модули, значения тайм-аутов, значения настройки кэша и значения активных нитей. Подробные сведения о настройке Caching Proxy представлены в Caching Proxy Administration Guide.
Также для повышения быстродействия можно внести и определенные изменения в конфигурацию операционной системы; например, настроить TCP и ARP, увеличить ограничения дескрипторов файлов, синхронизировать системное время, настроить карты сетевого интерфейса (NIC) и следовать общепринятым нормам выполнения задач администрирования системы.
ВАЖНАЯ ИНФОРМАЦИЯ: Caching Proxy доступен во всех версиях Edge Components исключая следующее:
В данном разделе обсуждаются вопросы аппаратного сетевого обеспечения, касательно функциональности Caching Proxy в сети.
Для сервер proxy необходимо выделить большой объем памяти. Caching Proxy может использовать 2 Гб виртуального адресного пространства при настройке большого кэша памяти. Память также требуется для ядра, общих библиотек и сетевых буферов. Таким образом сервер proxy может потреблять 3 или 4 Гб физической памяти. Обратите внимание, что кэш памяти является значительно более быстродейственным, чем дисковый кэш, и подобное изменение конфигурации может существенно ускорить производительность.
Важно иметь большой объем свободного пространства на жестком диске в системе, в которой установлен Caching Proxy. Особенно важно это в случае применения дискового кэша. Процесс чтения и записи на жесткий диск потребляет немало системных ресурсов. Несмотря на эффективность процедур ввода-вывода Caching Proxy, механические ограничения быстродействия жесткого диска могут ограничить производительность в случае настройки Caching Proxy для применения дискового кэша. Узкое место ввода-вывода жесткого диска можно оптимизировать за счет таких приемов, как использование нескольких жестких дисков для кэширования и файлов протокола, а также применение жестких дисков с меньшим временем поиска, высокой скоростью вращения шпинделя и скоростью передачи данных.
Характеристики сети, такие как скорость, тип и число NIC, а также скорость подключения к сервер proxy влияют на производительность Caching Proxy. Обычно для повышения производительности рекомендуется использовать два NIC в системе сервер proxy: один для входящего потока данных и один для исходящего потока данных. Это необходимо, так как один NIC может достигнуть максимального ограничения из-за одного лишь потока данных запросов и ответов HTTP. Более того, размер NIC должен составлять не менее 100 Мб и они должны быть всегда настроены на работу в режиме полного дуплекса. Причиной этому является возможность возникновения ошибок и падения производительности из-за автоматического согласования между маршрутизаторами и коммутирующим оборудованием. Наконец, следует отметить, что скорость сетевого соединения чрезвычайно важна. Например, невозможно обслужить большой объем запросов и достигнуть оптимальной производительности если соединением с системой Caching Proxy является загруженное соединение T1.
Центральный процессор системы Caching Proxy может стать одним из ограничивающих производительность факторов. Мощность центрального процессора влияет на время, необходимое для обработки запросов, а число центральных процессоров в сети влияет на масштабируемость. Важно, чтобы требования к центральному процессору сервер proxy отвечали имеющейся среде, особенно для моделирования пиковой нагрузки запросов, обслуживаемых сервер proxy.
Для повышения производительности рекомендуется масштабировать всю архитектуру, а не только отдельные аппаратные устройства. Не важно сколько аппаратных устройств добавляется в одну систему, у аппаратного обеспечения все равно имеется максимальный уровень производительности.
В данном разделе описываются вопросы сетевой архитектуры, которые следует учитывать при добавлении функциональности Caching Proxy в вашу сеть.
Если Web-сайт вашей компании является популярным среди пользователей, спрос на просмотр его информационного наполнения может превысить возможности одной сервер proxy, что приведет к увеличению времени отклика. Для оптимизации быстродействия сети рекомендуется рассмотреть возможность добавления кластеров, распределение нагрузки для систем Caching Proxy или применение общей архитектуры кэша с удаленным доступом к кэшу (RCA) в сетевой архитектуре.
Одним из способов масштабирования архитектуры является добавление кластеров в сервер proxy и применение компонента Load Balancer для распределения нагрузки между ними. Добавление кластеров к сервер proxy положительно влияет не только на производительность и масштабируемость, но и на избыточность и надежность. Одиночная сервер proxy представляет единую точку сбоя, если происходит сбой или она становится недоступна из-за сетевого сбоя, пользователи не смогут работать с вашим Web-сайтом.
Также рассмотрите возможность применения общей архитектуры кэша с RCA. Общая архитектура кэша распространяет общий виртуальный кэш между несколькими серверами Caching Proxy, обычно использующими междукэшевый протокол вроде Internet Cache Protocol (ICP) или Cache Array Routing Protocol (CARP). Предназначением RCA является максимизация частоты попаданий в кэш с кластерами, с помощью большого виртуального кэша.
Производительность повышается благодаря применению массива RCA из сервер proxy, по сравнению с одной автономной Caching Proxy или даже кластером из автономных систем Caching Proxy. По большей части повышение производительности достигается за счет увеличения общего размера виртуального кэша, что ведет к увеличению попаданий в кэш и снижает несогласованность и латентность. Благодаря RCA в кэше находится только одна копия определенного документа. За счет кластера из сервер proxy увеличивается общий размер кэша, но есть вероятность, что несколько серверов proxy будут извлекать и кэшировать одинаковую информацию. При этом общее число попаданий в кэш не увеличивается.
RCA обычно используется в сценариях хостинга информационного наполнения крупных предприятий. Однако, полезность RCA не ограничивается только развертываниями в крупных предприятий. Использовать RCA имеет смысл если нагрузка на сеть требует использования кластера кэш-серверов и если большинство запросов представляют собой попадания в кэш. В зависимости от настройки сети, RCA не всегда повышает производительность из-за увеличения числа TCP-соединений, используемых клиентом при настроенном RCA. Это происходит потому, что RCA не только отвечает за обслуживание URL, для которых отмечается наивысшая степень соответствия, но также должен перенаправлять запросы другим элементам или кластерам при получении запроса для URL, для которого отсутствует наивысшая степень соответствия. Это означает, что любой элемент массива RCA может иметь больше открытых соединений TCP чем при работе в качестве автономного сервера.
Основной вклад в повышение производительности вносят функции кэширования Caching Proxy. Тем не менее, кэширование сервер proxy может стать узким местом при неправильной настройке. Для определения оптимальной конфигурации кэша следует приложить определенные усилия для анализа характеристик потока данных. Тип, размер, количество и атрибуты информационного наполнения влияют на производительность сервер proxy с точки зрения времени, необходимого для извлечения документов из исходных серверов и нагрузки на сервер. Когда вы поймете, какой тип потока данных Caching Proxy собирается направить через proxy или извлечь из кэша, вы сможете учесть эти характеристики при настройке сервер proxy. Например, зная что 80% кэшируемых объектов являются изображениями (*.gif или *.jpg) и имеют размер порядка 200 Кб, вы сможете более точно настроить параметры кэширования и определить размер кэша. Кроме того, для настройки Caching Proxy важно знать, если большую часть информационного наполнения составляют персонализированные динамические страницы, не подлежащие кэшированию.
Анализ характеристик потока данных позволяет вам определить, можно ли оптимизировать производительность кэша с помощью дискового кэша или кэша памяти. Также знания о характеристиках сетевого потока данных позволяют определить, можно ли повысить производительность с помощью функции динамического кэширования Caching Proxy.
Дисковые кэши наиболее подходят для сайтов с большим объемом кэшируемой информации. Например, если информационное наполнение сайта имеет большой объем (более 5 Гб) и кэшируется 80 - 90% информационного наполнения, рекомендуется использовать дисковый кэш. Однако, известно, что использовать кэш памяти (RAM) быстрее и есть масса сценариев, согласно которым применение кэша памяти пригодно для крупных сайтов. Например, если процент попадания в кэш Caching Proxy не важен или используется общая конфигурация кэша, более практично использовать кэш в памяти.
Caching Proxy может кэшировать и аннулировать динамическое информационное наполнение (JSP и результаты сервлетов) создаваемых динамическим кэшем WebSphere Application Server, предоставляя виртуальное расширение кэша Application Server в сетевые кэши. Включение кэширования динамически создаваемого информационного наполнения положительно влияет на производительность сети в среде с большим количеством динамически создаваемых публичных Web-страниц, устаревающих на основе логики приложений или событий, таких как сообщение из базы данных. Срок хранения страницы конечен, но можно также задать триггер устаревания при создании страницы; таким образом, хосты без динамического кэширования и функции аннулирования должны рассматривать подобные страницы как имеющие значение времени хранения в кэше равным нулю.
Если подобная динамически создаваемая страница будет запрошена более одного раза, одним или несколькими пользователями, динамическое кэширование в этом случае обеспечит снижение нагрузки на хосты информационного наполнения вашей сети. Использование динамического кэширования также повышает быстродействие сети за счет снижения времени отклика пользователям устраняя сетевые задержки и сокращая потребление пропускной способности из-за уменьшения числа Internet-транзакций.
Работая совместно с хостами информационного наполнения, например, с WebSphere Application Server или с компонентом Application Server Caching Proxy, компонент Application Server Load Balancer позволяет повысить коэффициент готовности и масштабируемость вашей сети. (Общие сведения о Edge components приведены в разделе Введение в WebSphere Application Server Edge components). Load Balancer применяется в корпоративных сетях и устанавливается между сетью Internet и базовыми корпоративными серверами. Load Balancer выполняет роль единой точки присутствия компании в Internet, даже если компания использует несколько базовых серверов из-за высокой нагрузки или большого объема информационного наполнения.
Готовность достигается за счет распределения нагрузки и поддержки переключения.
ВАЖНАЯ ИНФОРМАЦИЯ: Caching Proxy доступен во всех версиях Edge Components исключая следующее:
Распределение нагрузки повышает готовность и масштабируемость Web-сайта за счет прозрачного распределения по кластерам серверов proxy и серверов приложений. Масштабируемость инфраструктуры IT можно существенно повысить за счет прозрачного добавления базовой вычислительной мощности.
Удовлетворить возросшую нагрузку можно скопировав информационное наполнение на нескольких хостах, но при этом потребуется сбалансировать нагрузку между ними. Служба доменных имен (DNS) обеспечивает базовое распределение нагрузки, но в некоторых ситуациях этого может оказаться недостаточно.
Более мощным решением распределения нагрузки между несколькими хостами информационного наполнения является применение компонента Load Balancer Dispatcher, как описано в Рис. 5. В данной конфигурации все хосты информационного наполнения (системы, помеченные 5), хранят одинаковое информационное наполнение. Они формируют кластер с распределенной нагрузкой, а одному сетевому интерфейсу системы Load Balancer (4) присвоено имя хоста и IP-адрес, выделенный кластеру. Когда пользователь, работающий в одной из систем помеченных 1, запрашивает файл X, запрос переправляется по сети Internet (2) и попадает в внутреннюю корпоративную сеть через шлюз Internet (3).Dispatcher перехватывает запрос, так как его URL привязан к имени хоста и IP-адресу Dispatcher. Dispatcher определяет, какой хост информационного наполнения в кластере в данный момент является наиболее подходящим для обработки запроса и пересылает ему запрос. Выбранный хост, при включенном методе пересылки MAC, возвращает файл X напрямую клиенту (то есть файл X не проходит через Load Balancer).
Условные обозначения: 1--Клиент 2--Internet 3--Маршрутизатор/Шлюз 4--Dispatcher 5--Хост информационного наполненияПо умолчанию Dispatcher применяет карусельное распределение нагрузки типа DNS, но несмотря на это, многие DNS адресуются неадекватно. В отличие от DNS, здесь выполняется отслеживание доступности хоста информационного наполнения, и клиенты не переплавляются к недоступному хосту информационного наполнения. Более того, оценивается текущая нагрузка на хосты информационного наполнения, за счет отслеживания новых, активных и завершенных соединений. Можно еще более оптимизировать распределение нагрузки, активировав необязательные компоненты советника и диспетчера Load Balancer, отслеживающие состояние хоста информационного наполнения еще более точно и использующие дополнительную информацию в процессе принятия решений о распределении нагрузки. Диспетчер позволяет присвоить различный вес некоторым факторам, учитываемым при принятии решения, что позволяет более точно настроить распределение нагрузки для сайта.
Load Balancer Dispatcher также может выполнять распределение нагрузки и для нескольких систем Caching Proxy. Если ваш корпоративный Web-сайт популярен среди пользователей, спрос на его информационное наполнение может превысить возможности одной сервер proxy, что ведет к снижен и производительности сервер proxy.
Можно настроить несколько систем Caching Proxy, выполняющих функции proxy,для одного хоста информационного наполнения (примерно как в конфигурации, описанной в Рис. 1), но если ваш сайт является довольно популярным и требует применения нескольких серверы proxy, вероятно, вам понадобится несколько хостов информационного наполнения, распределение нагрузки для которых выполняется Load Balancer. Рис. 6 описывает данную конфигурацию. Dispatcher с отметкой 4 распределяет нагрузку на кластер из двух серверы proxy (5), и Dispatcher с отметкой 7 распределяет нагрузку для кластера из трех хостов информационного наполнения (8).
Условные обозначения: 1--Клиент 2--Internet 3--Маршрутизатор/Шлюз 4--Dispatcher 5--сервер proxy 6--Кэш 7--Dispatcher 8--Хосты информационного наполненияИмя хоста кластера Dispatcher, отмеченное 4, является именем хоста, отображаемым в URL корпоративного Web-информационного наполнения (то есть, является именем Web-сайта, видимым в Internet). Имя хоста кластера для Dispatcher, отмеченное 7, не видно в Internet, поэтому для него можно задать любое значение. В качестве примера, для фирмы ABC Corporation подходящим именем хоста для Dispatcher с отметкой 4 может быть www.abc.com, тогда как Dispatcher с отметкой 7 может быть, к примеру,http-balancer.abc.com.
Предположим, что браузеру одной из клиентских систем с отметкой 1 требуется получить доступ к файлу X, расположенному на сервере с отметкой 8. Запрос HTTP передается по Internet (2) и попадает во внутреннюю корпоративную сеть через шлюз (3). Маршрутизатор направляет запрос к Dispatcher с отметкой 4, который передает его к сервер proxy (5), который в данный момент является оптимальным для обслуживания запроса,согласно алгоритму распределения нагрузки. Если сервер proxy содержит файл X в кэше (6), он возвращает его непосредственно браузеру, минуя Dispatcher с отметкой 4.
Если у сервер proxy копия файла X в кэше отсутствует, он создает новый запрос с собственным именем хоста в поле происхождения в заголовке и отправляет его к Dispatcher с отметкой 7. Load Balancer определяет какой из хостов информационного наполнения (8) в данный момент наиболее пригоден для обслуживания запроса, и переправляет запрос ему. Хост информационного наполнения извлекает файл X из хранилища и возвращает его напрямую сервер proxy, минуя Dispatcher с отметкой 7. сервер proxy при необходимости кэширует файл X и пересылает его браузеру, минуя Dispatcher с отметкой 4.
Если вы предоставляете доступ к Интернет большому числу клиентов, единственного proxy может оказаться недостаточно для эффективной обработки их запросов. Если Caching Proxy будет перегружен, то для клиентов время ответов может оказаться ниже, чем при прямом доступе к Интернет. А также при неполадке Caching Proxy или отсутствия связи с ним из-за сбоев сети, доступ к Интернет прекращается. Избежать этого можно, установив несколько систем Caching Proxy и используя Диспетчер Load Balancer для распределения нагрузки между ними.
Без использования Диспетчера вы сможете обеспечить transparent proxy с несколькими системами Caching Proxy, только если ваши маршрутизаторы могут обрабатывать данные такого типа для нескольких Caching Proxy. Не все маршрутизаторы поддерживают это. Можно обеспечить службу пересылающего proxy с нескольких системах Caching Proxy без использования Диспетчера, но при этом необходимо настроить клиентские браузеры на использование одной из систем Caching Proxy в качестве основного proxy. Если в этом Caching Proxy произойдет неполадка или он станет недоступен или перегружен, конечные пользователи могут потерять доступ к Интернет. Для того чтобы избежать этой ситуации, можно создать файл автоматической конфигурации proxy (PAC) (как описано в разделе Прозрачный пересылающий Caching Proxy (только в системах Linux)), которая перенаправит браузер на один из вторичных caching proxy. Файл PAC не предназначен для распределения нагрузки между системами Caching Proxy. Однако, если один из Caching Proxy получает намного больше запросов, чем другой, производительность понизится, и время ответов клиентским браузерам станет выше. Для того чтобы распределить нагрузку между всеми клиентами, необходимо настроить приблизительно равное количество браузеров на использование каждого Caching Proxy, и поддерживать распределение вручную при добавлении и удалении браузеров.
Рис. 7 иллюстрирует конфигурацию сети, в которой Диспетчер распределяет нагрузку в кластере систем Caching Proxy. Один из сетевых интерфейсов системы Диспетчера имеет специальное имя хоста и IP-адрес в кластере. Клиентские браузеры настраиваются для передачи их запросов на этот хост кластера. Например, когда браузеру в одной из клиентских систем, помеченных 1, необходим доступ к файлу X на хосте информационного наполнения (7), он направляет свой запрос на имя или адрес хоста кластера, где Диспетчер (2) перехватывает его и перенаправляет подходящему Caching Proxy (3). Caching Proxy создает новый запрос, передает его через шлюз предприятия (5) в Интернет (6), и сохраняет возвращенный файл, если он подходит, в своем кэше (4), как это более подробно описано в разделе Пересылающий Caching Proxy.
Диспетчер определяет, когда одна из систем Caching Proxy становится недоступной, и автоматически перенаправляет запросы на другую. Это позволяет выключать Caching Proxy для обслуживания, не прекращая доступ к Интернет. Диспетчер имеет многочисленные опции конфигурации, с помощью которых можно управлять факторами, влияющими на распределение нагрузки. Можно также установить вспомогательные программы Диспетчера в системах Caching Proxy для отслеживания их состояний и возврата информации Диспетчеру. Более подробная информация находится в WebSphere Application Server Load Balancer Administration Guide. Использование нескольких Caching Proxy потенциально может оказаться неоптимальным, потому что несколько Caching Proxy могут кэшировать один и тот же файл, если разные клиенты запросили его у разных систем Caching Proxy. Для того чтобы избежать этой избыточности, вы можете настроить доступ к удаленному кэшу (RCA), который включает все серверы Proxy в определенную группу, использующую общий кэш. Серверы Proxy в группе RCA используют одинаковый алгоритм для определения того, какой Caching Proxy ответственен за данный URL. Когда Caching Proxy перехватывает URL, за который он не ответственен, он передает запрос на подходящий Caching Proxy. Ответственный Caching Proxy выполняет необходимую работу для выполнения этого запроса, или получая ответ из кэша, или перенаправляя на соответствующий хост информационного наполнения и кэшируя полученный файл. Затем ответственный Caching Proxy передает файл исходному Caching Proxy, который доставляет его запрашивающему конечному пользователю.
Если в группе RCA ответственный за данный URL Caching Proxy недоступен, тогда первоначальный Caching Proxy, получивший запрос клиента, будет непосредственно обращаться к хосту информационного наполнения (или к резервному Caching Proxy, если он определен). Это значит, что пользователи могут получать доступ к файлам, если хотя бы один Caching Proxy в группе RCA работает нормально.
Эта конфигурация удовлетворяет высоким требованиям к доступу к Интернет, используя Диспетчер для распределения нагрузки между несколькими системами Caching Proxy. Единственное слабое место - это Диспетчер. Если он выходит из строя или становится недоступным из-за сбоя в сети, клиентские браузеры не могут получить доступ к Caching Proxy или Интернет. Избежать этого можно, настроив другой Диспетчер в качестве резервного, как это проиллюстрировано на рисунке Рис. 8.
Здесь браузер, выполняемый в одной из систем, помеченных 1, в обычной ситуации направляет свой запрос на файл X основному Диспетчеру (2), который перенаправляет его Caching Proxy (4), выбранному на основании критерия распределения нагрузки Диспетчера. Caching Proxy создает новый запрос, передает его через шлюз предприятия (6) в Интернет (7) хосту информационного наполнения (8), и сохраняет возвращенный файл, если он подходит, в своем кэше (5), (более подробно эта стадия процесса описана в разделе Пересылающий Caching Proxy).
В этой конфигурации резервный Диспетчер (3) не выполняет распределение нагрузки, пока основной работает без сбоя. Основной и резервный Диспетчеры отслеживают состояние друг друга, периодически обмениваясь сообщениями, которые называются пульс. Если резервный Диспетчер обнаруживает сбой основного, он автоматически перед на себя обязанности по распределению нагрузки, перехватывая запросы, направляемые к основному имени и IP-адресу хоста кластера. Также возможно настроить два Диспетчера для взаимной высокой готовности. В этом случае каждый из них активно выполняет распределение нагрузки для отдельного кластера серверов Caching Proxy, одновременно выполняя роль резервного для своего напарника. Более подробная информация находится в WebSphere Application Server Load Balancer Administration Guide.
Диспетчер обычно не использует много вычислительных ресурсов или ресурсов памяти, и в системе Диспетчера можно параллельно выполнять и другие приложения. Если для вас важно минимизировать расходы на оборудование, возможно выполнение резервного Диспетчера в той же системе, что и Caching Proxy. Рис. 9 описывает подобную конфигурацию, в которой резервный Диспетчер выполняется в той же системе (3), что и Caching Proxy.
Load Balancer выполняет роль единой точки присутствия для ваших корпоративных хостов информационного наполнения. Преимущества этого заключаются в том, что вы можете рекламировать имя хоста кластера и адрес в DNS, вместо имени хоста и адреса каждого хоста информационного наполнения, что гарантирует определенный уровень защиты от простых атак и обеспечивает единый облик вашего корпоративного Web-сайта. Для дополнительного расширения доступности Web-сайта,настройте дополнительный резервный Load Balancer для основного Load Balancer, как описывается в Рис. 10. Если один Load Balancer становится недоступным или выходит из строя, конечные пользователи все равно смогут получать данные с хоста информационного наполнения.
Условные обозначения: 1--Клиент 2--Internet 3--Маршрутизатор/Шлюз 4--Основной Dispatcher 5--Резервный Dispatcher 6--Хост информационного наполненияВ обычной ситуации браузер, выполняемый в одной из систем, помеченных 1, направляет запросы к файлу X к имени хоста кластера, привязанного к основному Load Balancer (4). Dispatcher направляет запрос к хосту информационного наполнения (6),выбранного на основе критериев распределение нагрузки Dispatcher. Хост информационного наполнения отправляет файл X напрямую в браузер, через корпоративный шлюз (3) и Internet (2), но минуя Load Balancer.
Резервный Dispatcher (5) не выполняет распределение нагрузки пока основной работает без сбоя. Основной и резервный Dispatcher отслеживают состояние друг друга, периодически обмениваясь сообщениями, которые называются пульс. Если резервный Dispatcher обнаруживает сбой основного, он автоматически перед на себя обязанности по распределению нагрузки, перехватывая запросы, направляемые к основному имени хоста кластера и IP-адресу.
Также возможно настроить два Dispatcher для взаимной высокой готовности. В этом случае каждый из них активно выполняет распределение нагрузки для отдельного кластера или хостов информационного наполнения, одновременно выполняя роль резервного для своего напарника. (В Load Balancer for IPv4 and IPv6 взаимная высокая готовность не поддерживается).
Dispatcher обычно не использует много вычислительных ресурсов или ресурсов памяти, и в системе Load Balancer можно параллельно выполнять и другие приложения. Если для вас важно минимизировать расходы на оборудование, возможно выполнение резервного Dispatcher в одной из систем кластера, для которого выполняется распределение нагрузки. Рис. 11 описывает подобную конфигурацию, в которой резервный Dispatcher выполняется в одном из хостов информационного наполнения (5) в кластере.
Условные обозначения: 1--Клиент 2--Internet 3--Маршрутизатор/Шлюз 4--Основной Dispatcher 5--Резервный Dispatcher и хост информационного наполнения 6--Хост информационного наполненияВАЖНАЯ ИНФОРМАЦИЯ: Компонент CBR Content Based Routing доступен во всех поддерживаемых платформах исключая следующее:
В качестве альтернативы для данного типа установки можно использовать способе пересылки CBR компонента Load Balancer' Dispatcher для обеспечения маршрутизации на основе информационного наполнения запросов HTTP и HTTPS без использования Caching Proxy. Дополнительные сведения содержатся в WebSphere Application Server Load Balancer Administration Guide.
Load Balancer for IPv4 and IPv6 поддерживает только способ пересылки MAC компонента. Пересылка nat и cbr не поддерживается.
Работая совместно с Application Server Caching Proxy, компонент Application Server Load Balancer позволяет распространять запросы между несколькими базовыми серверами, являющимися хостами для различного информационного наполнения. (Общие сведения о Edge components приведены в разделе Введение в WebSphere Application Server Edge components).
Если компонент маршрутизация на основе информационного наполнения Load Balancer Content Based Routing (CBR) установлен вместе с Caching Proxy, запросы HTTP можно распределять на основе URL или прочих определяемых администратором свойств, что позволяет отказаться от необходимости хранить идентичное информационное наполнение на всех базовых серверах.
Применение CBR особенно оправдано если Web-серверы должны выполнять несколько различных функций или других типов служб. Например, Web-сайт электронного магазина должен отображать каталог товаров, большая часть которого является статичной, и принимать заказы, то есть выполнять интерактивные приложения, такие как сценарий Common Gateway Interface (CGI), для получения артикулов товаров и данных о пользователях. Зачастую более эффективно использовать две различные группы систем для выполнения различных функций и использовать CBR для маршрутизации различных типов потоков данных между различными системами. Точно так же, компания может использовать CBR для обеспечения более качественных платных услуг посетителям Web-сайта по сравнению с бесплатными, перенаправляя платящих за доступ клиентов к более мощным Web-серверам.
CBR маршрутизирует запросы основываясь на созданных вами правилах. Наиболее распространенным типом является правило информационного наполнения, переправляющее запросы исходя из пути URL. Например, компания ABC может использовать правила, направляющие запросы к URL http://www.abc.com/catalog_index.html в один кластер серверов, а запросы к http://www.abc.com/orders.html - в другой кластер. Также имеются правила, направляющие запросы исходя из IP-адреса клиента, отправившего их, или прочих характеристик. Более подробные сведения содержатся в главах Руководство по управлению WebSphere Application Server Load Balancer, посвященных настройке CBR и расширенным функциям Load Balancer и CBR. Описания синтаксиса правил содержится в приложении Руководство по управлению WebSphere Application Server Load Balancer, посвященном типам правил CBR.
Рис. 12 описывает простую конфигурацию, в которой компоненты CBR Load Balancer и Caching Proxy установлены вместе в системе, помеченной 4 и перенаправляют запросы к трем хостам информационного наполнения (6, 7 и 8), содержащим различное информационное наполнение. Когда пользователь, работающий в одной из систем помеченных 1, запрашивает файл X, запрос переправляется по сети Internet (2) и попадает в внутреннюю корпоративную сеть через шлюз Internet (3). сервер proxy перехватывает запрос и передает его компоненту CBR в той же системе, который обрабатывает URL запроса и определяет, что хост 6 содержит файл X. сервер proxy создает новый запрос файла X, и если функция кэширования включена, определяет, доступен ли файл для кэширования, когда хост 6 возвращает его. Если файл доступен для кэширования, сервер proxy сохраняет его копию в кэше (5) перед его передачей конечному пользователю. Маршрутизация других файлов работает таким же образом: запросы файла Y переправляются к хосту информационного наполнения 7, а запросы к файлу Z переправляются к хосту информационного наполнения 8.
Условные обозначения: 1--Клиент 2--Internet 3--Маршрутизатор/Шлюз 4--Компонент CBR Caching Proxy и Load Balancer 5--Кэш 6, 7, 8--Хост информационного наполненияРис. 13 описывает более сложную конфигурацию, возможно, подходящую для Web-магазина. Компоненты CBR Load Balancer и сервер proxy установлены в системе, отмеченной 4 и переправляют запросы в две системы Load Balancer. Система Load Balancer, помеченная 6, распределяет нагрузку на кластер хостов информационного наполнения ( 8), содержащих наиболее статические данные каталога электронного магазина, тогда как Load Balancer с отметкой 7 распределяет нагрузку кластера Web-серверов, обрабатывающих заказы (9).
Когда пользователь, работающий в одной из систем помеченных 1, обращается к URL каталога электронного магазина, запрос переправляется по сети Internet (2) и попадает в внутреннюю корпоративную сеть через шлюз Internet (3). сервер proxy перехватывает запрос и передает его в компонент CBR той же системы, который обрабатывает URL и определяет, что система Load Balancer с отметкой 6 предназначена для обработки данного URL. сервер proxy создает новый запрос на получение доступа и отправляет его в Load Balancer, где определяется, какой из хостов, помеченных 8, в данный момент доступен для обслуживания запроса (исходя из заданного вами критерия). Этот хост информационного наполнения передает данные каталога непосредственно в сервер proxy, минуя Load Balancer. Как и в предыдущем примере сервер proxy определяет, доступно ли информационное наполнение для кэширования и сохраняет его в кэше (5) при возможности.
Конечный пользователь размещает заказ, обращаясь к URL страницы заказа электронного магазина с помощью гиперссылки в каталоге. Запрос проходит тот же путь, что и запрос на доступ к каталогу, исключая то, что компонент CBR системы 4 перенаправляет его в систему Load Balancer, помеченную 7. Load Balancer пересылает его к наиболее подходящему Web-серверу,помеченному 9, отвечающему напрямую сервер proxy. Так как данные заказа обычно создаются динамически, сервер proxy, вероятно, не кэширует их.
Условные обозначения: 1--Клиент 2--Internet 3--Маршрутизатор/Шлюз 4--Компонент CBR Caching Proxy и Load Balancer 5--Кэш 6, 7--Load Balancer 8--Хост информационного наполнения 9--Web-серверФункция CBR Load Balancer поддерживает привязку cookie. Это означает, что субъект сервера, обслуживающего первые запросы конечного пользователя записывается в специальном пакете данных (cookie), включаемом в ответ сервера. Когда конечный пользователь повторно обращается к тому же URL в указанный вами интервал времени, и запрос содержит cookie, CBR направляет запрос к исходному серверу, без повторного применения стандартных правил. Обычно это позволяет улучшить время ответа если на сервере имеется информация о конечном пользователе, которую не требуется получать повторно (например, номер кредитной карты).
В данной части приведено описание бизнес-сценариев, использующих IBM WebSphere Application Server Edge components. Это проверенные и готовые решения, обеспечивающие отменную производительность, доступность, масштабируемость и надежность.
Данная часть содержит следующие главы:
Банковское решение бизнес-клиент
Простой Web-сайт электронной коммерции представляет собой сеть бизнес-клиент. Во время первой фазы роста Internet, бизнес обычно фокусировался на создании простого присутствия в Web. Корпоративная информация и каталоги просто преобразовывались в электронный вид и публиковались на Web-сайтах. Покупка товаров производилась путем предоставления адреса электронной почты, номера телефона и факса и даже автоматических форм. Однако настоящий электронный шоппинг был недоступен. Все транзакции выполнялись с задержкой, так как заказы обрабатывались сотрудниками.
На втором этапе эта задержка была устранена, операции продаж были рационализированы за счет внедрения защищенных корзин для прямых электронных покупок. Синхронизация со складскими базами данных и интеграция с системами банковского обслуживания являются необходимыми элементами для выполнения этих транзакций продаж. Нельзя продать недоступный товар, и нельзя взять у клиента деньги за него. Точно также невозможно взять продукт со склада и отправить его клиенту без подтверждения факта оплаты.
На третьем этапе корпоративные Web-сайты превратились в динамические сайты, расценивающие потребителей как клиентов, предоставляющие им персонализированное информационное наполнение.
В следующем сценарии включены Load Balancer и Caching Proxy.
ВАЖНАЯ ИНФОРМАЦИЯ: Caching Proxy доступен во всех версиях Edge Components исключая следующее:
Рис. 14 демонстрирует небольшой коммерческий Web-сайт, предлагающий эффективную систему просмотра каталога товаров. Все клиентские запросы проходят сквозь брандмауэр к Dispatcher, направляющему запросы в кластер из серверы proxy с активными кэшами,выполняющими роль суррогатных серверов для Web-серверов. Серверы измерений объединены с серверы proxy для обеспечения распределения нагрузки данных для Dispatcher. Такая схема снижает сетевую нагрузку на Web-серверы и изолирует их от прямого взаимодействия с Internet.
Рис. 15 иллюстрирует второй этап развития коммерческого Web-сайта, предоставляющего эффективную систему просмотра каталога товаров и защищенные корзины для потенциальных заказчиков. Все клиенты перенаправляются в соответствующую ветвь сети с помощью Dispatcher, отделяющего запросы на основе Internet-протокола. Запросы HTTP передаются на статичный Web-сайт, запросы HTTPS передаются в сеть обработки заказов. Основной статический Web-сайт в се еще обслуживается кластером серверы proxy с активными кэшами, выполняющими роль суррогатов для Web-серверов. Эта часть сети является зеркальным отражением сети первого этапа.
Раздел электронной коммерции Web-сайта также обслуживается кластером серверы proxy. Однако узлы Caching Proxy дополнены несколькими встраиваемыми модулями. Квитирование SSL переведено на аппаратную карту шифрования, идентификация выполняется с помощью встраиваемого модуля Access Manager (бывшего Policy Director). Модуль Dynamic Caching снижает нагрузку на WebSphere Application Server, сохраняя общие данные. Встраиваемый модуль в сервера приложений при необходимости аннулирует объекты и Dynacache.
Все приложения корзины привязаны к базе данных клиентов, использованной для идентификации пользователя. Это предотвращает повторный ввод личной информации пользователем, один раз для идентификации и один раз для совершения покупок.
Такая сеть разделяет поток данных исходя из действий клиентов, а также снимает ресурсоемкие процессы идентификации SSL и обслуживания корзин с основного Web-сайта. Такой двойной Web-сайт позволяет сетевому администратору настроить несколько серверов и повысить производительность в зависимости от роли сервера внутри сети.
Рис. 16 иллюстрирует третий этап развития сетей бизнес-клиент, в котором статичные Web-сайты используют метод динамической презентации. Кластер сервера proxy расширен для поддержки кэширования динамического Web-информационного наполнения и составления в одно целое фрагментов страниц, написанных в соответствии с протоколом Edge Side Includes (ESI). Вместо применения механизмов расширенных функций сервера для создания Web-страниц на серверах информационного наполнения и передачи этих зависящих от клиента, некэшируемых страниц через всю сеть, механизмы ESI позволяют собирать страницы из информационного наполнения кэша на краю сети,снижая потребление пропускной способности и уменьшая время отклика.
Механизмы ESI являются неотъемными элементами в подобном сценарии третьего этапа, где каждый клиент получает персонализированную домашнюю страницу с Web-сайта. Составные части этих страниц извлекаются из серии серверов WebSphere Application Servers. Серверы приложений, содержащие промежуточную бизнес-логику и связи с защищенными базами данных, изолированы за брандмауэром.
Рис. 17 содержит эффективное решение электронного банковского обслуживания, схожее с сетью бизнес-клиент, описанной в Сеть бизнес-клиент. Все клиентские запросы проходят через брандмауэр к Dispatcher, разделяющему поток данных согласно Internet-протоколу. HTTP-запросы переходят в кластер серверов proxy с активными кэшами, выполняющими роль суррогатных серверов для Web-серверов. Серверы измерений объединены с серверами proxy для обеспечения распределения нагрузки данных для Dispatcher. Это снижает сетевую нагрузку на Web-серверы и создает дополнительный буфер между ними и сетью Internet.
Запросы HTTPS передаются в защищенную сеть, созданную для предоставления клиентам персональной финансовой информации и обеспечения выполнения транзакций электронного банковского обслуживания. Кластер расширенных серверов proxy обеспечивает масштабируемость сайта. Эти серверы proxy поддерживают кэширование динамического Web-информационного наполнения и сбор фрагментов страницы, написанных для соответствия протоколу Edge Side Includes (ESI). Аппаратная карта шифрования управляет процедурой согласования SSL, что значительно снижает время обработки для хоста сервера proxy, идентификацию клиента выполняет Access Manager (ранее называвшийся Policy Director).
Набор кластеров серверов приложений распределяет обработку запросов, разделяя бизнес-логику, содержащуюся в компонентах EJB, от данного уровня презентации, содержащегося в сервлетах и файлах JSP. Каждый из этих кластеров управляется отдельным сервером сеанса.
В следующем сценарии включены Load Balancer и Caching Proxy.
ВАЖНАЯ ИНФОРМАЦИЯ: Caching Proxy доступен во всех версиях Edge Components исключая следующее:
В Рис. 18 показана сеть Web-портала, созданная для поддержки большого объема потока данных и предоставления каждому клиенту персонализированного информационного наполнения. Для минимизации нагрузки на различные серверы сеть не обслуживает поток данных SSL. Так как портал не доставляет промежуточные данные, вопрос защиты является не особенно важным. Для баз данных, содержащих ИД клиента, пароли и настройки, важно быть умеренно защищенными и неповрежденными, но это требование не оказывает влияния на производительность оставшихся элементов Web-сайта.
Все клиентские запросы проходят через брандмауэр к Dispatcher, распределяющему нагрузку между кластером серверов proxy с активными кэшами, выполняющими роль суррогатных серверов для Web-серверов. Серверы измерений объединены с серверами proxy для обеспечения распределения нагрузки данных для Dispatcher.
Фактический динамический Web-сайт является кластером серверов приложений, создающих фрагменты ESI, передаваемые для сборки серверам proxy. Из-за ослабления защиты каждый сервер приложений выполняет все необходимые функции для создания Web-сайта. Все серверы приложений являются идентичными. Если один из серверов приложений выходит из строя, сервер сеансов может переправить запросы другим серверам, обеспечивая высокую готовность всего сайта. Такая конфигурация также позволяет выполнить быструю эскалацию Web-сайта в случае резкого увеличения потока данных, например, при размещении на сайте какого-либо специального события. Для сайта можно быстро настроить дополнительные серверы proxy или серверы приложений.
Все статичное информационное наполнение, например, файлы изображений и заготовки текста, хранятся на отдельных Web-серверах, позволяя выполнять их обновление без риска повредить более сложные серверы приложений.
В следующем сценарии включены Load Balancer и Caching Proxy.
ВАЖНАЯ ИНФОРМАЦИЯ: Caching Proxy доступен во всех версиях Edge Components исключая следующее:
Данная часть описывает процедуры для установки Edge components.
Данная часть содержит следующие главы:
Системные требования для Edge components
Установка Edge components с помощью программа установки
Установка Caching Proxy с помощью системных пакетных утилит
Установка Load Balancer с помощью системных пакетных утилит
В раздел приведены ссылки на аппаратные и программные требования для Edge components и содержатся основные инструкции по применению Web-браузеров с формами Caching Proxy Настройка и управление и с электронной справкой Load Balancer.
Информация о поддерживаемых аппаратных и программных средствах для WebSphere Application Server, Версия 6.1 Edge components содержится на следующей Web-странице: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921.
Установка SDK: Java 2 SDK автоматически устанавливается с Load Balancer на всех платформах.
Минимальные требования к браузеру
Для настройки Caching Proxy с помощью форм настройки и управления ваш браузер должен отвечать следующим требованиям:
Для систем Linux и UNIX: Для рекомендуемых версий браузеров Mozilla и Firefox обратитесь к следующему Web-сайту и перейдите на страницу поддерживаемого программного обеспечения: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921.
Для систем Windows: Для рекомендуемых версий браузеров Internet Explorer, Mozilla и Firefox обратитесь к следующему Web-сайту и перейдите на страницу поддерживаемого программного обеспечения: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921.
ОГРАНИЧЕНИЯ: Левая вертикальная полоса прокрутки формы управления может не отображаться в браузерах если число развернутых элементов слишком велико для отображения в окне браузера. Из-за этого элементы внизу списка выходят за границы окна браузера и оказываются недоступными. Для устранения этой неполадки ограничьте число развернутых элементов в левом меню. Если число развернутых элементов велико, сверните некоторые из них, чтобы в окне браузера появились элементы, находящиеся внизу списка.
Для корректного отображения форм операционная система, в которой установлен браузер, должна содержать соответствующий набор шрифтов для языка, на котором создана форма. Язык интерфейса браузера может отличаться от языка форм.
Например, в системе Solaris 9 выполняется китайская версия сервера proxy. В хосте Solaris загружен браузер Mozilla с английским интерфейсом. Этот браузер можно использовать локально для редактирования форм Настройка и управление. (Формы загружаются в браузер с помощью набора символов, применяемого сервером proxy, в данном случае - китайский язык; однако, формы будут отображены некорректно если браузер и операционная система не настроены для просмотра набора символов, отправленного сервером proxy).
Если рабочая станция Windows с поддержкой китайского языка доступна для удаленного подключения к серверу proxy, можно загрузить китайскую версию браузера Netscape на рабочую станцию Windows и использовать этот браузер для ввода значений в формы. Второй подход имеет преимущество для администратора за счет согласованного сохранения языка интерфейса.
Наборы шрифтов операционных систем существенно влияют на отображение в браузерах текстов на различных языках, особенно двухбайтовых символов. Например, определенный китайский шрифт в AIX отличается от китайского шрифта в Windows. Это ведет к возникновению некоторых разногласий во внешнем виде текста HTML и аплетов Java в формах Настройка и управление. Поэтому для оптимального результата рекомендуется использовать только браузеры, выполняемые в операционной системе Windows.
Примечание о применении браузера Mozilla 1.4 в S/390 и PowerPC
Компонент Java, устанавливаемый с Mozilla 1.4, следует обновить до версии 1.4.2 или выше для корректного отображения форм управления. Для обновления компонента выполните следующие действия:
Для применения электронной справки Load Balancer ваш браузер должен поддерживать следующие функции:
Применение браузера, не отвечающего этим требованиям, может привести к неправильному форматированию страниц и вызвать ошибки при запуске функций.
В раздел содержатся инструкции по установке Edge components с помощью программа установки.
Java 2 SDK устанавливается автоматически с Load Balancer на всех платформах.
После установки сценарии пакета Caching Proxy попытаются запустить сервер proxy с помощью конфигурации по умолчанию. Если используется порт 80, например другим Web-сервером, запустить сервер proxy не удастся.
ВАЖНАЯ ИНФОРМАЦИЯ: Caching Proxy доступен во всех версиях Edge Components исключая следующее:
Используйте программа установки для установки Edge Components в системе Windows:
Если Edge Components уже установлены, перед окном выбора компонентов появится окно Опции обслуживания. Выберите переключатель Изменить, затем нажмите кнопку Далее. Откроется окно выбора компонентов.
Ограничение: Нажатие клавиши табуляции в окне подтверждения лицензии переключает между опциями Я согласен и Я не согласен. Однако, нельзя с помощью клавиши табуляции перейти к опциям навигации Назад, Далее или Отменить. Вместо этого, для перехода к опциям навигации используйте Shift+Tab. Кроме того, клавиша Enter работает только для кнопок навигации, а для выбора опций Я согласен и Я не согласен нужно использовать пробел.
При установке с компакт-диске можно использовать программа установки для установки Edge components в системы Linux и UNIX следующим образом:
# ./installПоявится окно приветствия.
программа установки приступит к установке выбранных Edge components и обязательных пакетов.
Ограничение: Нажатие клавиши табуляции в окне подтверждения лицензии переключает между опциями Я согласен и Я не согласен. Однако, нельзя с помощью клавиши табуляции перейти к опциям навигации Назад, Далее или Отменить. Вместо этого, для перехода к опциям навигации используйте Shift+Tab. Кроме того, клавиша Enter работает только для кнопок навигации, а для выбора опций Я согласен и Я не согласен нужно использовать пробел.
В системе Red Hat Linux 3.0 Update 3: При выполнении программы установки для Edge components кнопки интерфейса не будут работать если панель GUI была развернута и затем восстановлена. Для устранения данного дефекта выполните следующие действия:
В системах Linux и UNIX: При использовании программы установки для установки Edge components можно использовать программу GUI удаления из системы для удаления Edge components. Тем не менее, программу GUI удаления из системы Edge components нельзя применять для удаления пакета обновлений, установленного с помощью внутренних команд. Вначале требуется удалить пакет обновлений с помощью внутренних команд (команд операционной системы) перед удалением из системы компонентов с помощью программу удаления GUI.
Более подробная информация об использовании внутренних команд находится в разделах Установка Caching Proxy с помощью системных пакетных утилит и Установка Load Balancer с помощью системных пакетных утилит.
раздел содержит инструкции по установке Caching Proxy с помощью системных пакетных утилит.
После установки сценарии пакета Caching Proxy попытаются запустить сервер proxy с помощью конфигурации по умолчанию. Если используется порт 80, например другим Web-сервером, запустить сервер proxy не удастся.
ВАЖНАЯ ИНФОРМАЦИЯ: Caching Proxy доступен во всех версиях Edge Components исключая следующее:
С помощью системы установки пакетов вашей операционной системы установите пакеты в порядке, указанном в Табл. 2. Следующая процедура подробно описывает типичные действия, необходимые для выполнения задачи.
su - root Пароль: password
cd mount_point/package_directory/
В AIX:
installp -acXd ./имя-пакета
В HP-UX:
swinstall -s source/ имя-пакета
В Linux:
rpm -i ./имя-пакета
В Solaris:
pkgadd -d ./имя-пакета
Компонент | Установленные пакеты (в рекомендованном порядке) |
---|---|
Caching Proxy |
|
Документация для Edge Components |
doc-en_US1 |
Прим.:
|
Пакет документации только на английском языке. Переводы набора документации компонента Edge находятся на следующем Web-сайте: www.ibm.com/software/webservers/appserv/ecinfocenter.html.
Для удаления пакетов из системы:
В AIX:
installp -u имя-пакета
Для удаления из системы всех пакетов Caching Proxy введите команду:
installp -u wses
В HP-UX:
swremove имя-пакета
Для запроса установленных пакетов Caching Proxy введите команду:
swlist | grep WSES
Пакеты будут удалены из системы в обратном порядке по сравнению с установкой.
В Linux:
rpm -e имя-пакета
Для запроса установленных пакетов Caching Proxy введите команду:
rpm -qa |grep -i wses
Пакеты будут удалены из системы в обратном порядке по сравнению с установкой.
В Solaris:
pkgrm имя-пакета
Для запроса установленных пакетов Caching Proxy введите команду:
pkginfo | grep WSES
Пакеты будут удалены из системы в обратном порядке по сравнению с установкой.
В раздел описывается установка Load Balancer в системах AIX, HP-UX, Linux и Solaris:
В зависимости от установки Load Balancer поставляются не все пакеты, перечисленные в этом разделе.
Рекомендуемый порядок установки пакетов немного отличается для установок Load Balancer for IPv4 and IPv6. Важно заметить, что пакет компонентов администрирования должен быть установлен после пакета компонентов диспетчера. Рекомендуемый порядок установки пакетов для Load Balancer for IPv4 and IPv6 с помощью системных средств: базовый, лицензии, диспетчер, администрирование, документация, Metric Server.
При переходе от предыдущей версии Load Balancer или повторной установке операционной системы, перед новой установкой можно сохранить файлы предыдущей конфигурации или файлы сценариев для Load Balancer.
Если вы вышли из системы после установки Load Balancer, необходимо перезапустить службы Load Balancer при повторном входе в систему.
Табл. 5 содержит список наборов файлов AIX для Load Balancer и рекомендуемый порядок установки с помощью средства установки системных пакетов.
Компоненты Load Balancer | Наборы файлов AIX |
---|---|
Базовый | ibmlb.base.rte |
Администрация (с сообщениями) |
|
Драйвер устройства | ibmlb.lb.driver |
Лицензия | ibmlb.lb.license |
Компоненты Load Balancer (с сообщениями) |
|
Документация (с сообщениями) |
|
Metric Server | ibmlb.ms.rte |
Пакет документации только на английском языке. Переводы набора документации Edge Component находятся на следующем Web-сайте: www.ibm.com/software/webservers/appserv/ecinfocenter.html.
Перед установкой Load Balancer для AIX убедитесь в следующем:
installp -u ibmlbили, для удаления предыдущих версий, введите:
installp -u ibmndДля удаления из системы определенных наборов файлов укажите их последовательно вместо указания одного имени пакета ibmlb.
При установке продукта можно установить некоторые или все следующие элементы:
Рекомендуется использовать SMIT для установки Load Balancer для AIX, так как SMIT гарантирует автоматическую установку всех сообщений.
mkdir /cdrom mount -v cdrfs -p -r /dev/cd0 /cdrom
Пакеты | команды |
---|---|
Базовый | installp -acXgd устройство ibmlb.base.rte |
Администрация (с сообщениями) | installp -acXgd устройство ibmlb.admin.rte ibmlb.msg.язык.admin |
Драйвер устройства | installp -acXgd устройство ibmlb.lb.driver |
Лицензия | installp -acXgd устройство ibmlb.lb.license |
Компоненты Load Balancer (с сообщениями). Включают в себя: Dispatcher, CBR, Site Selector, Cisco CSS Controller и Nortel Alteon Controller |
installp -acXgd device ibmlb.component.rte ibmlb.msg.language.lb |
Документы (с сообщениями) | installp -acXgd device ibmlb.doc.rte ibmlb.msg.en_US.lb |
Metric Server | installp -acXgd устройство ibmlb.ms.rte |
installp -ld устройство
При установке с компакт-диска, чтобы размонтировать компакт-диск введите следующую команду:
unmount /cdrom
Проверьте установку продукта с помощью следующей команды:
lslpp -h | grep ibmlb
Если продукт был установлен полностью, появится следующий вывод:
ibmlb.base.rteibmlb.admin.rte
ibmlb.lb.driveribmlb.lb.licenseibmlb.компонент.rte
ibmlb.doc.rte
ibmlb.ms.rteibmlb.msg.language.admin
ibmlb.msg.en_US.doc
ibmlb.msg.language.lb
Будут использованы следующие пути установки Load Balancer:
В данном разделе описывается установка Load Balancer в HP-UX с компакт-диска.
Перед началом установки убедитесь в наличии у вас прав доступа root для установки ПО.
При наличии установленной более ранней версии, удалите ее прежде, чем приступить к установке текущей версии. Вначале убедитесь в остановке сервера и исполнителя. Затем, для удаления Load Balancer см. Инструкции по удалению пакетов из системы.
Табл. 7 содержит список имен пакетов установки для Load Balancer и рекомендуемый порядок установки пакетов с помощью системной утилиты установки пакетов.
HP-UX не поддерживает локаль бразильский португальский (pt_BR). HP-UX поддерживает следующие локали:
Следующая процедура подробно описывает действия, необходимые для выполнения задачи.
su - root Пароль: password
Выполните команду установки
swinstall -s /источник имя-пакета
где источник - это абсолютный путь к каталогу, содержащему пакет, а имя-пакета - имя пакета.
Например, следующая команда запустит установку базового пакета для Load Balancer (ibmlb.base) из корневого каталога компакт-диска
swinstall -s /источник ibmlb.base
Для установки всех пакетов Load Balancer выполните следующую команду, если установка производится из корневого каталога компакт-диска:
swinstall -s /источник ibmlb
Выполните команду swlist для просмотра списка всех установленных пакетов. Например,
swlist -l fileset ibmlb
Для удаления пакетов из системы воспользуйтесь командой swremove. Пакеты будут удалены из системы в обратном порядке по сравнению с установкой. Например, так:
swremove ibmlbДля удаления отдельного пакета (например, Cisco CSS Controller)
swremove ibmlb.cco
Будут использованы следующие пути установки Load Balancer:
В данном разделе описывается процесс установки Load Balancer в Linux с компакт-диска Edge components.
Перед установкой Load Balancer, убедитесь в следующем:
rpm -e имя-пакетаПри удалении из системы выполните удаление пакетов в обратном порядке по сравнению с установкой, удаляя пакеты администрирования в последнюю очередь.
Установочный образ представляет собой файл в формате lblinux-версия.tar.
tar -xf lblinux-версия.tarВ результате появится следующий набор файлов с расширением .rpm:
Где --
Пакет документации только на английском языке. Переводы набора документации Edge Component находятся на следующем Web-сайте: www.ibm.com/software/webservers/appserv/ecinfocenter.html.
rpm -i пакет.rpm
Системы Red Hat Linux: Из-за известных неполадок в Red Hat Linux необходимо также удалить файлы _db* RPM, иначе произойдет ошибка.
Важно устанавливать пакеты в порядке, приведенном в следующем списке пакетов, необходимых для каждого компонента.
rpm -i --nodeps пакет.rpm
rpm -qa | grep ibmlb
Если продукт был установлен целиком, появится следующий вывод:
Будут использованы следующие пути установки Load Balancer:
При удалении из системы выполните удаление пакетов в обратном порядке по сравнению с установкой, удаляя пакеты администрирования в последнюю очередь.
В данном разделе описана процедура установки Load Balancer в Solaris с компакт-диска Edge components.
Перед тем, как начать процедуру установки, убедитесь ,что вы вошли в систему в качестве пользователя root и предыдущие версии продукта удалены.
Для удаления из системы остановите все серверы и исполнители. Затем, введите следующую команду:
pkgrm имя-пакета
pkgadd -d путьгде -d путь является именем устройства для дисковода компакт-дисков или каталогом на жестком диске, в котором расположен пакет, например: -d /cdrom/cdrom0/.
Ниже перечислены пакеты в рекомендуемом порядке их установки.
Пакет документации (ibmlbdoc) только на английском языке. Переводы набора документации Edge Component находятся на следующем Web-сайте: www.ibm.com/software/webservers/appserv/ecinfocenter.html.
При необходимости установки всех пакетов, просто введите all и нажмите клавишу Return. Если требуется установить только некоторые компоненты, укажите имена устанавливаемых пакетов через запятую или пробел и нажмите клавишу Return. Может появиться запрос на изменение прав доступа к имеющимся каталогам или файлам. Просто нажмите клавишу Return или укажите ответ yes. Необходимо также установить предварительные пакеты (так как установка происходит по алфавиту, а не по первоочередности). Если вы указали all, ответьте yes на все вопросы и установка будет успешно завершена.
Если требуется установить только компонент Dispatcher с документацией и Metric Server, следует установить следующие пакеты: ibmlbbase, ibmlbadm, ibmlblic, ibmdisp, ibmlbdoc и ibmlbms.
pkginfo | grep ibm
Будут использованы следующие пути установки Load Balancer:
В данной части описаны процедуры создания базовых демонстрационных сетей с помощью Edge components. Эти сети не предназначены для применения в производственной среде. Процесс первичной настройки сети может прояснить многие вопросы для администраторов, не знакомых с продуктом. Полное описание всех функций компонента и сведения о расширенной настройке содержатся в Caching Proxy Administration Guide и Load Balancer Administration Guide.
Данные процедуры позволяют использовать в любом узле любую компьютерную систему, поддерживаемую компонентом.
Данная часть содержит следующие главы:
В Рис. 19 показана простая сеть сервер proxy из трех компьютерных систем, расположенных в трех сетевых узлах. Эта сеть соединяет сервер Proxy с выделенным хостом информационного наполнения (IBM HTTP Server), расположенным на сервере 2, сервер Proxy обслуживает хост. Визуально это представлено соединением с сетью Internet, расположенным между рабочей станцией и сервером 1.
ВАЖНАЯ ИНФОРМАЦИЯ: Caching Proxy доступен во всех версиях Edge Components исключая следующее:
Для создания сети Caching Proxy выполните следующие действия в указанном порядке:
Необходимо наличие следующих аппаратных и программных компонентов:
Установите и настройте Caching Proxy следующим образом:
# htadm -adduser /opt/ibm/edge/cp/server_root/protect/webadmin.passwd
При появлении запроса запустите программу htadm, указав имя пользователя, пароль и фактическое имя для администратора.
Установите и настройте Caching Proxy следующим образом:
cd "Program Files\IBM\edge\cp\server_root\protect" htadm -adduser webadmin.passwd"
При появлении запроса запустите программу htadm, указав имя пользователя, пароль и фактическое имя для администратора.
Выполните следующие действия с рабочей станции:
Выполните следующие действия с рабочей станции:
Рис. 20 иллюстрирует базовую сеть Load Balancer с тремя локально подключенными рабочими станциями и применением метода пересылки MAC компонента Dispatcher для распределения нагрузки потока данных Web между двумя Web-серверами. Такая конфигурация схожа с распределением нагрузки других потоков данных приложений TCP или UDP без сохранения состояния.
Для создания сети Load Balancer выполните указанные процедуры в следующем порядке:
Необходимо наличие следующих аппаратных и программных компонентов:
Рабочая станция | Имя | IP-адрес |
---|---|---|
1 | сервер1.компания.com | 9.67.67.101 |
2 | сервер2.компания.com | 9.67.67.102 |
3 | сервер3.компания.com | 9.67.67.103 |
Маска сети = 255.255.255.0 |
Имя= www.компания.com IP=9.67.67.104
Добавьте псевдоним для www.компания.com в циклический интерфейс на сервер2.компания.com и сервер3.компания.com.
ifconfig lo0 alias www.компания.com netmask 255.255.255.0
ifconfig lo0:1 www.компания.com 127.0.0.1 up
Теперь все необходимые действия по настройке двух Web-серверов выполнены.
С помощью Dispatcher можно создавать конфигурацию посредством командной строки, мастера настройки или графического интерфейса пользователя (GUI).
При использовании командной строки выполните следующие действия:
dscontrol executor start
dscontrol cluster add www.компания.com
dscontrol port add www.компания.com:80
dscontrol server add www.компания.com:80:сервер2.компания.com
dscontrol server add www.компания.com:80:сервер3.компания.com
dscontrol executor configure www.компания.com
dscontrol manager start
Теперь Dispatcher выполняет распределение нагрузки на основе производительности сервера.
dscontrol advisor start http 80
Теперь Dispatcher следит, чтобы клиентские запросы не отправлялись на отказавший Web-сервер.
Базовая настройка с подключенными локально серверами завершена.
ВАЖНОЕ ЗАМЕЧАНИЕ: В установке Load Balancer for IPv4 and IPv6 синтаксис команды Dispatcher (dscontrol) идентичен с одним важным исключением. Разделителем для команд dscontrol служит символ @, а не двоеточие (:). (Разделитель, отличный от двоеточия, необходим так как формат IPv6 использует двоеточие для в схеме адресации).
Например (из предыдущего примера настройки Dispatcher):
dscontrol port add www.компания.com@80
dscontrol server add www.компания.com@80@сервер2.компания.com
dscontrol server add www.компания.com@80@сервер3.компания.com
Дополнительная информация о применении установки Load Balancer for IPv4 and IPv6 содержится в главе, посвященной развертывания Dispatcher в Load Balancer for IPv4 and IPv6, содержащей сведения об ограничениях и различиях настройки, в Руководство по управлению WebSphere Application Server Load Balancer.
При использовании мастера настройки, выполните следующие действия:
dsserver
Мастер поможет вам пошагово создать базовую конфигурацию для компонента Dispatcher. Вам будут заданы вопросы о вашей сети и пошагово будет выполнена настройка кластера для Dispatcher для распределения нагрузки потока данных для группы серверов.
Мастер настройки содержит следующие окна:
Для запуска GUI выполните следующие действия:
dsserver