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

Сведения о совместимости и настройке кэширования для CSS 11000

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


Содержание


Введение

Этим документом является рекомендация для определения кэширования и вопросов совместимости при осуществлении Коммутаторов Контент-сервиса Cisco (CSS) 11000/11500.

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

Требования

Ознакомление с этим документом требует наличия следующих знаний:

  • Шлюз по умолчанию кэша должен быть CSS.

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

Эта информация применяется ко всему CSS Cisco (11000 и 11500) рабочий Выпуск 3.0x Программного обеспечения webns или выше.

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

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

Дополнительные сведения об условных обозначениях см. в документе Технические рекомендации Cisco. Условные обозначения.

Конфигурация кэша

Сравнение коммутатора уровня 2 с коммутатором потока

CSS является потоковым коммутатором в отличие от коммутаторов уровня 2 (L2). Карты коммутатора потока идут на порты на основе сведений IP, в противоположность сведениям уровня MAC, как в коммутаторе L2. Функции коммутации потока позволяют CSS распознавать контент, смотреть пакеты синхронизации/старта (SYN) TCPили HTTP GET, принимать решения по содержимому, а не только переадресовывать кадры. В кэширующихся средах коммутатор потока требует, чтобы вы направили все пакеты, прибывающие из кэша, предназначенного клиентам.

Маршрутизация

Поскольку CSS должен исполнять роль шлюза по умолчанию для кэша и прокладывать маршрут для всех пакетов в кэше, в системе CSS должна быть полная таблица маршрутизации.

Сервисы

Если настроить службу при помощи команды type transparent-cache, CSS заменит MAC-адрес назначения MAC-адресом кэша и перенаправит IP-пакеты в кэш для сохранения IP-адреса назначения. Если кэш не может слушать случайно для всего порта 80 трафиков, то необходимо настроить кэш как proxy-cache типа; однако, сервисы прокси-кэша не могут использовать метод аварийного переключения обхода. Поскольку MAC-пакеты направлены в кэш, кэш должен быть напрямую подсоединен к устройству. Если сделать это не удается, следует подключить его через устройство L2, которое нельзя использовать совместно с клиентом или подключением к Интернету.

Если служба настроена как "proxy-cache" или "transparent-cache", автоматически создается невидимый список доступа (ACL), с помощью которого исходный IP-адрес кэша может обходить все правила содержимого и получать страницы с исходного сервера. Запускаясь в Версии WebNS 4.0, можно ввести команду no cache-bypass для прозрачного кэширования и сервисов прокси-кэша для отключения автоматического обхода правил содержимого.

Функционирование двух действующих CSS невозможно, если каждый из них имеет непосредственно присоединенный кэш и нагрузка распределяется между ними по типу "прозрачный кэш" (transparent-cache), если только каждый кэш не имеет прямой связи со своим коммутатором. Коммутатор получит запрос от клиента и, возможно, передаст этот запрос в кэш, подсоединенный к другому коммутатору, который обнаружит входящий запрос и сопоставит его со своим правилом и, возможно, решит передать его в кэш, подсоединенный к первому коммутатору. Поскольку пересылка этих пакетов производится по MAC-адресу, невозможно построить правильный список ACL для выполнения этого действия.

Сравнение уровня 4 и уровня 5

Когда информация, требуемая, чтобы совпасть с правилом или принять решение распределения нагрузки, не находится в SYN TCP, но находится в GET HTTP, правило, как полагают, является Уровнем 5 (L5); поэтому, когда вы добавляете URL, балансировочный метод домена, хэша - домена или хэша URL, правило является автоматически L5 и вызывает спуфинг. Применение спуфинга рекомендуется даже в тех случаях, когда не является обязательным, так как за счет этого обеспечивается защита кэша от синхронных лавинных атак. Конфигурация L5 обеспечивает и Extension Qualifier List (EQL) и обход аварийного переключения, который заставляет коробку имитировать соединение с исходным сервером, в противоположность кэшу. Если правилом контента считается L5, это означает, что CSS подменяет соединения с абонентами.

Асимметрия

Если существует маршрут назад клиентам от исходного сервера, который не проходит через CSS, то у вас есть асимметрия, в противном случае известная как триангуляция. При использовании правила L5 и существует обход, коробка имитирует соединение с исходным сервером, и адрес возврата переходит непосредственно к клиенту, где это тогда очень быстро отброшено, так как клиент не распознает порядковый номер. Вам необходимо либо исправить вашу асимметрию, послать что-нибудь в кэш и использовать линейный перехват управления при отказе, либо использовать равноправный информационный обмен трансляции сетевых адресов (NAT) при помощи транслирования IP-адресов ваших клиентов с целевой группой.

Баланс

Рекомендуется использовать балансировочный метод хэша URL и хэша - домена. Хэш-домен выполняет хэширование по тегу всего узла и затем определяет сервер, который должен обслуживать этот домен, обеспечивая равномерное распределение нагрузки. Метода балансировки хеширования URL работает аналогично методу хэширования домена, но использует URL как источник данных в противоположность метке узла.

Если используется служба кэширующего сервера-посредника, то балансировка производится на основе первого запроса GET постоянного соединения, и до тех пор, пока второй запрос GET отвечает этому же правилу, перебалансировка не выполняется, так как это может вызвать дублирование узлов в кэшах (обратитесь к нижеследующему разделу по предварительной выборке). В WebNS 4.0 можно настроить CSS на разрыв постоянного соединения и перебалансировку путем выполнения команды no persistent по правилу содержимого. Каждый раз, когда вводится команда no persistent, желательно также использовать команду WebNS 4.0 persistence reset remap. Команда сброса устойчивости используется для определения, как следует разрывать устойчивые подключения. По умолчанию является перенаправлением сброса устойчивости, которое заставляет CSS передавать сброс TCP и перенаправление HTTP 302 клиенту, вынуждая клиент установить новое соединение. Internet Explorer (IE) 5.0 имеет известные проблемы с получением нескольких перенаправлений обратно на тот же домен. Команда persistence reset remap сохраняет клиентское соединение и перемещает соединение по тыловой подсети от одного сервера к другому.

Failover

Когда правило контента состоит из служб типа прозрачного кэша и используется один из методов баланса кэширования, можно использовать метод транзитной передачи с переключением при отказе, чтобы разрешить пересылку запросов, предназначенных для конкретного кэша, на исходный сервер в случае недоступности кэша. Обратитесь к проблеме асимметрии выше.

Обход EQL

CSS могут быть сконфигурированы списком расширений файла для отправления в кэш. Список называется EQL. В случае добавления EQL к строке URL в правиле контента, правило соответствует только запросам с расширениями файлов, которые указаны в списке. CSS может также быть настроен для обхода EQL путем изменения приложения на правиле содержимого для обхода. Если в WebNS 4.0 необходимо, чтобы CSS обслуживал каждый запрос при постоянном соединении с соответствующей точкой назначения на основе EQL, необходимо выполнить команду no persistent для правила содержимого. Как только правило содержимого обошлось, если вы хотите следующее, входят в постоянное соединение, которое будет передаваться кэшу, если это кэшируемо, тогда необходимо выйти, сохранение обхода WebNS 4.0 отключают команду global. Всякий раз, когда происходит отключение устойчивости, нужно выполнить глобальную команду 4.0 persistence reset remap для избежания проблем с IE 5.0.

Обход кэша

Некоторые кэши имеют возможность настроить список сайтов, которые должны обойтись кэшем. CSS несовместим с функцией обхода большинства кэшей. CSS позволяет настроить списки сетевых квалификаторов (NQLs), которые позволяют настроить список IP-адресов или сетей, который можно добавить в один пункт в ACL.

Возможность обхода параметров URL

CSS может быть настроен для автоматического обхода любых URL, которые имеют параметры. Эти запросы не будут удовлетворены кэшем (например, котировка акций).

Возможность предварительной выборки

При обеспечении сервиса cache клиентам переменная, которая создает самую большую задержку в ответ время, - когда кэш не содержит страницу, которую запрашивают, потому что это тогда должно пойти и получить его. Цель распределения нагрузки кэшей состоит в том, чтобы увеличить вероятность попадания в кэш. Некоторые кэши поддерживают возможность предварительной выборки, что позволяет им анализировать данные, возвращенные от первоначального запроса get и заранее получать объекты на данной странице, прежде чем клиент запросит их в явной форме. Иногда это может привести к дополнительной загрузке Интернет-магистрали, если клиент должен был остановить загрузку страницы, но объем трафика при этом скорее всего незначителен.

При использовании прозрачное кэширование, то функция обхода EQL на CSS ломает алгоритм предварительной выборки, потому что по умолчанию EQL не включает домашнюю страницу, которая является просто GET для "/." Without the main home page for a site, the cache does not have the main page to work off of for pre-fetching. Во-вторых, если мы не посылаем динамические запросы в кэш, на исходный сервер будут направляться два запроса, один от CSS, а другой – из кэша. Клиенты должны принять решение, в чем состоит их цель, и затем определить, какие функциональные возможности каждого продукта следует объединить

В узлах, где развернуто несколько кэшей, выравниватель нагрузки должен попытаться достичь максимальной эффективности попыток убедиться в удачном обращении к кэшу. CSS использует несколько алгоритмов балансировки нагрузки, которые были разработаны для оптимизации числа попаданий в кэш. Поскольку этот коммутатор является коммутатором L5, он может обращаться за сведениями в HTTP GET, что другие устройства выравнивания нагрузки делать не могут. Например, можно определить кэш для отправки запроса на основе запрошенного доменного имени или URL-адреса. При условии использования алгоритма хэширования домена, все запросы содержимого, имеющего одинаковые теги хоста, отсылаются в один кэш. Таким образом, увеличивается вероятность размещения содержимого в этом же кэше. Если предварительная выборка используется с прозрачными кэшами, кэш будет получать запрос раньше коммутатора, переадресуя запрос ему, что может привести к получению страницы не тем кэшем. В данном случае может понадобиться отключить функцию предварительной выборки.

При обсуждении прокси - кэшей IP - заголовок не предоставляет никого действительно достоверные сведения для распределения нагрузки способом для обеспечения оптимизации количества попаданий в кэш; IP - адрес назначения не изменяется. Единственной информацией, которая пройдет дальше, будет IP-адрес источника, который реально ничего не означает относительно пользования Интернетом. Коммутатор все еще может просматривать метку узла и информацию URL для создания этих решений. Так как кэши прокси обычно используют постоянное соединение с клиентом, загружен коммутатор только уравновешивающими решениями, основанными на первом HTTP GET, и всеми последующими GET, идущими на тот же самый кэш. Поскольку стабильное соединение не прерывается, такой подход целесообразно использовать вместе с возможностью предварительной выборки для всех последующих GETS на том же подключении. Запускаясь в Выпуске 4.0 WebNS, можно настроить CSS для ломки этих соединений если вы, так требуйте путем запуска команды no persistent.

Связанные обсуждения сообщества поддержки Cisco

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


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


Document ID: 12574