Интерфейсы и модули Cisco : Модуль коммутации контента Cisco

Пример настройки прозрачного кэширования с модулем переключения содержимого

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


Содержание


Введение

Этот документ предоставляет пример конфигурации для прозрачного кэширования с помощью Cisco Cache Engines и Модуля коммутации контента (CSM). Прозрачное кэширование является способом, используемым, чтобы прозрачно перехватить трафик от Web-браузер и перенаправить его к устройству кэша для получения содержания, которое ранее кэшировалось.

Другим методом, чтобы сделать прозрачное кэширование является Протокол WCCP. Преимущество прозрачного кэширования по WCCP состоит в том, что CSM посмотрел на URL, который запрашивает клиент, и решает, должен ли трафик быть передан кэшу или нет. В то время как страницы dynamic (результат сценария) получены непосредственно из сервера, не переходя к кэшу, запросы о статических файлах, таких как gif или изображения в формате JPEG получены из кэша.

Перед началом работы

Требования

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

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

Сведения в документе приведены на основе данных версий аппаратного и программного обеспечения:

  • Версия CSM 3. x

  • Версия 5.1 Сетевого программное обеспечение содержимого приложения (ACNS)

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

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

Настройка

В этом разделе содержатся сведения о настройке функций, описанных в этом документе.

Схема сети

В данном документе используется сетевая установка, показанная на следующей схеме.

/image/gif/paws/50381/csm_transparent_caching.jpg

Конфигурации

В данном документе используется следующая конфигурация:


module ContentSwitchingModule 4 
 vlan 501 server
  ip address 192.168.30.97 255.255.254.0
!
 vlan 499 client
  ip address 192.168.10.97 255.255.254.0
  gateway 192.168.10.1
!
 vlan 500 server
  ip address 192.168.20.97 255.255.254.0
!
 serverfarm CACHES
  no nat server 


!--- This is a transparent redirect; do not change the destination IP address.

  
no nat client
  predictor hash url


!--- Use URL hashing to make sure the request for a specific URL always goes to the same server.

  
real 192.168.30.200
   inservice
  real 192.168.30.201
   inservice
!
 
serverfarm FORWARD
  no nat server 
  no nat client
  predictor forward


!--- This serverfarm tells the CSM not to load balance.
!--- The CSM instead uses its routing table to forward the traffic.

!

map CACHEABLE url


!--- In this example, you want to only redirect requests for certain  file types.
!--- This is not mandatory.
!--- You can also adjust this to something more realistic.

  
match protocol http url *.html
  match protocol http url *.gif
  match protocol http url *.jpg
  match protocol http url *.exe
  match protocol http url *.zip
!   
 
policy CACHEABLE


!--- The policy is the way to link the map with a serverfarm.

  
url-map CACHEABLE
  serverfarm CACHES
!
 
vserver FROMCACHE


!--- This rule is for traffic originating from the caches (when they have 
!--- to retrieve content from the origin server).

  
virtual 0.0.0.0 0.0.0.0 any
  vlan 501


!--- The VLAN command guarantees that you limit this vserver to the cache VLAN.

  
serverfarm FORWARD


!--- Use the serverfarm FORWARD command to disable load balancing for this traffic.
!--- In this example, you need forward requests from the caches to the origin server.
!--- You could, however, load balance this traffic to a series of Web servers, that is,
!--- when doing reverse proxy caching.

  
persistent rebalance
  inservice
!
 
vserver INTERCEPT


!---- This is the rule to transparently redirect requests from the client to the caches.

  
virtual 0.0.0.0 0.0.0.0 tcp www
  vlan 499
  serverfarm FORWARD


!--- The default action is forward; no load balancing.
!--- This is for requests that do not match the policy.

  
persistent rebalance
  slb-policy CACHEABLE


!--- Traffic matching the policy is load balanced to the caches.

  
inservice
!
 
vserver NONHTTP


!--- Non-HTTP traffic from the clients is forwarded.

  
virtual 0.0.0.0 0.0.0.0 any
  vlan 499
  serverfarm FORWARD
  persistent rebalance
  inservice
!

Проверка

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

  • покажите mod csm X vserver подробность name name

  • покажите, что mod csm X ведет подробность

EOMER#show mod csm 4 vser name intercept det
INTERCEPT, type = SLB, state = OPERATIONAL, v_index = 22
  virtual = 0.0.0.0/0:80 bidir, TCP, service = NONE, advertise = FALSE
  idle = 3600, replicate csrp = none, vlan = 499, pending = 30, layer 4
  max parse len = 2000, persist rebalance = TRUE
  ssl sticky offset = 0, length = 32
  conns = 0, total conns = 3
  Default policy:
    server farm = FORWARD, backup = <not assigned>
    sticky: timer = 0, subnet = 0.0.0.0, group id = 0
  Policy          Tot matches  Client pkts  Server pkts
  -----------------------------------------------------
  CACHEABLE       2            410          926          
  (default)       5            20           17          

Проверьте, что трафик совпал с политикой (трафик, перенаправленный к кэшам), или если трафик был передан (соответствие на политике по умолчанию).

EOMER#show mod csm 4 conn det

    prot vlan source                destination           state       
----------------------------------------------------------------------
In  ICMP 499  192.168.11.41         192.168.21.4          ESTAB       
Out ICMP 500  192.168.21.4          192.168.11.41         ESTAB       
    vs = NONHTTP, ftp = No, csrp = False

In  ICMP 501  192.168.10.107        10.48.66.102          ESTAB       
Out ICMP 499  10.48.66.102          192.168.10.107        ESTAB       
    vs = FROMCACHE, ftp = No, csrp = False

In  TCP  499  192.168.11.41:4402    192.168.21.4:80       REQ_WAIT    
Out TCP  501  192.168.21.4:80       192.168.11.41:4402    REQ_WAIT    
    vs = INTERCEPT, ftp = No, csrp = False

In  TCP  501  192.168.11.41:32784   192.168.21.4:80       ESTAB       
Out TCP  500  192.168.21.4:80       192.168.11.41:32784   ESTAB       
    vs = FROMCACHE, ftp = No, csrp = False

Кэш был настроен для IP-спуфинга. Вы видите в выходных данных, выше которых существует соединение от клиента 192.168.11.41 к серверу 192.168.21.4 замеченных на VLAN 499 и подобное соединение, замеченное на VLAN 501. Первый является реальным соединением от клиента, который был перенаправлен к кэшу (VLAN 501), и второй является соединением от кэша (имитирующий IP-адрес клиента) к исходному серверу.

Устранение неполадок

В этом разделе описывается процесс устранения неполадок конфигурации.


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


Document ID: 50381