Cервисы организации сетевого доступа к приложениям : Cisco LocalDirector серии 400

Методы настройки LocalDirector, сохраняющие привязку приложения к серверу

20 октября 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (22 августа 2015) | Отзыв


Cisco объявила о конце продажи для Cisco LocalDirector. "Для получения дополнительной информации см. касающиеся LocalDirector 400 Series ""Уведомления об окончании срока эксплуатации и продаж"" и ""Информационные бюллетени по продуктам (End-of-Life and End-of-Sale Notices and Product Bulletins).".


Содержание


Введение

Sticky или устойчивость сеансов связи являются обычно используемым методом, который гарантирует, что сеанс клиента остается связанным или придерживался того же сервера на время их сеанса. Это необходимо для коммерческого применения или защищенных приложений, которые требуют сохранения информации о сеанса или требуют регистрационной информации пользователя для входа и проверки подлинности и авторизация. Обычно в сценарии распределения нагрузки, каждый последовательный запрос от клиента снова оценен и может быть передан другому серверу во вращении распределения нагрузки. Когда все серверы имеют то же содержание и если пользователь только посмотрел на информацию, это - предпочтительный способ для распределения нагрузки. Когда устойчивость сеансов связи требуется, один из трех методов для sticky может использоваться на LocalDirector (LD) — sticky общего назначения, sticky Протокола SSL и cookie.

Предварительные условия

Условные обозначения

Дополнительные сведения об условных обозначениях в документах см. Cisco Technical Tips Conventions.

Требования

Для данного документа отсутствуют предварительные условия.

Используемые компоненты

Настоящий документ не имеет жесткой привязки к каким-либо конкретным версиям программного обеспечения и оборудования.

Сведения, содержащиеся в данном документе, были получены с устройств в специальной лабораторной среде. Все устройства, описанные в данном документе, были запущены с конфигурацией по умолчанию. Если вы находитесь в действующей сети, гарантируете понимание потенциального воздействия любой команды перед использованием его.

Методы задания конфигурации

Sticky общего назначения

Sticky общего назначения основывается на IP - адресе источника входящего соединения. Запросы от того же IP-адреса всегда отправляются к тому же серверу как тот, который был выбран на его первоначальном подключении. LD поддерживает внутреннюю таблицу, которая отслеживает эту информацию. Для настройки sticky общего назначения выполните команду sticky virtual_id minutes generic.

Виртуальный идентификатор (VID) определен в команде bind конфигурации LD, и мелкий параметр - то, сколько времени после того, как клиент разъединяет для ожидания до их информации о прочной связи (какой сервер они шли прошлый раз), очищен. Пользователь может застрять к другому серверу в следующий раз, когда они соединяются. По умолчанию является нулевыми минутами (отключенный sticky).

Предупреждение

Этот метод работает хорошо, пока входящие клиенты не работают через прокси, межсетевой экран или маршрутизатор, который выполняет переадресацию. В этой ситуации LD видит запросы всего пользователя, которые прибывают из того же IP-адреса, и отправляет все запросы к тому же серверу.

Sticky SSL

Sticky SSL основывается на ID Сеанса SSL (SID) клиента к подключению к серверу. Когда клиент соединяется, о SID выполняют согласование. SID передается в Заголовке HTTP и не зашифрован. SID быть считанным LD. Синтаксис команды является sticky минутами virtual_id ssl.

VID определен в команде bind конфигурации LD, и мелкий параметр - то, сколько времени после того, как клиент разъединяет для ожидания до их информации о прочной связи (какой сервер они шли прошлый раз), очищен. Пользователь может застрять к другому серверу в следующий раз, когда они соединяются. По умолчанию является нулевыми минутами (отключенный sticky).

Предупреждение

Internet Explorer 5.x и выше теперь пересматривает ИДЕНТИФИКАТОР SSL каждые две минуты. Для получения дополнительной информации об этом обратитесь к Internet Explorer, Пересматривает Соединение Уровня защищенных сокетов каждые две минуты leavingcisco.com.

Закрепленный сценарий на основе значения, которое постоянно изменяется, не работает хорошо. Как обходной путь, настройте LD так, чтобы клиент вошел на HTTP и был с балансировкой нагрузки среди ряда URL перенаправления, а не Web-серверов. Каждый из этих URL указывает назад к прямому IP (DIP) адрес на LD, который сопоставляет с одиночным реальным сервером. Теперь, когда клиент связывается с одиночным сервером, там не может быть с балансировкой нагрузки к другому real и может избежать этой проблемы. Для получения дополнительной информации об этой конфигурации обратитесь к Перенаправлению HTTP на HTTPS для системы Cisco LocalDirector Настройки.

Эта конфигурация требует использующих дополнительных открытых IP - адресов, один для каждого реального сервера, регистрации всех реальных серверов в DNS, и что клиент инициирует соединение на HTTP (порт 80), а не HTTPS (порт 443).

Cookie

Существует два типа cookie, что LD может работать с, cookie passive (cookie, которые вставлены Web-серверами сервера), и вставки cookie (cookie, вставленные самим LD).

Пассивная передача cookie Sticky

Синтаксис команды является sticky мелким названием пассивной передачи cookie virtual_id.

Эта команда включает сложное подключение на основе cookie, созданного sticky реальным сервером. LD изучает cookie и хранит его в памяти. Когда два идентичных cookie (два cookie с тем же NAME и VALUE) существуют на двух других серверах, режим пассивной передачи cookie в Версии 3.3.x LD не может работать должным образом. LD принимает решения о закрепленном отношении на основе cookie, полученного от Web-сервера. Вторые идентичные cookie разрывы первое закрепленное отношение на LD.

LD (который действует как прокси-сервер) получает новые клиентские соединения и просматривает HTTP-запрос GET на cookie, который совпадает один в памяти. Если существует соответствие, и время не истекло, LD передает пакеты к ранее выбранному sticky реальному серверу. LD тогда просматривает пакеты от sticky реального сервера, пока не обнаружен первый Ответ HTTP. Если существует соответствие, но время истекло, LD назначает соединение с новым реальным сервером. Если нет никакого маркера set-cookie в Ответе HTTP, LD прекращает действовать как прокси-сервер и передает все пакеты непосредственно к sticky реальному серверу. Если существует set-cookie в Ответе HTTP, LD хранит новый cookie в памяти и прекращает действовать как прокси-сервер для соединения. Если sticky реальный сервер не отвечает или возвращает RST TCP, LD назначает соединение с новым реальным сервером.

Если реальный сервер возвращает множественные cookie в Заголовке HTTP, просмотрах LD для первой директивы set-cookie и затем устанавливает закрепленное отношение (устойчивость) для последующих соединений на первом cookie, найденном в Заголовке HTTP.

Cookie-insert Sticky

Синтаксис команды для вставки cookie является sticky мелким названием Cookie-insert virtual_id домен .

Это - дополнительная команда. Эта команда включает сложное подключение на основе cookie, созданного LD. LD (действующий как прокси-сервер) получает новые клиентские соединения и просматривает Заголовок HTTP запроса GET о cookie. Если вы не обнаружены, LD назначает соединение с реальным сервером и создает cookie. Если cookie обнаружен, LD извлекает его для определения sticky ID реального сервера и времени окончания срока действия. Если время не истекло, LD вперед соединение с sticky реальным сервером. Если время истекло, LD назначает соединение с новым sticky реальным сервером и создает новый cookie.

Как только прочная связь установлена, LD прекращает действовать как прокси-сервер и передает все пакеты непосредственно к sticky реальному серверу. Опция Cookie-insert основывается на времени. Для часов клиента и сервера необычно точно синхронизироваться. Это, рекомендуют задать достаточно большое значение в мелком аргументе для покрытия возможных различий в синхронизации между клиентами и серверами. Название очень важно, поскольку это - строка, которую LD ищет и решает, к какому серверу пакеты должны быть переданы. Время синхронизации на LD также очень важно, и должно быть установлено во Время Гринвичского меридиана (GMT) в вооруженных силах или Согласованное текущее время (UTC) формат.


Дополнительные сведения


Document ID: 25746