[squid-users] Whether squid 3.5.2 can support rock at wccp tproxy environment really ?

[Amos Jeffries]

On 9/03/2015 4:38 p.m., johnzeng wrote:
> 
> 
> Hello Dear All :
> 
> I face a problem recently , When i config wccp ( tproxy ) environment (
> via using squid 3.5.2 ) ,
> 
> if i disable cache_dir rock part ,and it will be success for wccp(
> tproxy) , and enable cache_dir aufs
> 
> #cache_dir rock /accerater/webcache3/storage/rock1 2646 min-size=4096
> max-size=262144 max-swap-rate=250 swap-timeout=350
> 
> but if i enable cache_dir rock part ,and it will be failure for wccp(
> tproxy) and enable cache_dir aufs
> 
> cache_dir rock /accerater/webcache3/storage/rock1 2646 min-size=4096
> max-size=262144 max-swap-rate=250 swap-timeout=350
> 
> 
> Whether some of my config is error , if possible , please give me some
> advisement
> 

For starters,
 WCCP is a network protocol Squid uses to inform remote routers that it
is active and what traffic it can receive.
 rock is a layout format for bits stored on a disk.
 ... they are *completely* unrelated.



> 
> This is my config
> 
> 
> thanks
> 
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 
> coredump_dir /accerater/logs/webcache3/
> unlinkd_program /accerater/webcache3/libexec/unlinkd
> pid_filename /accerater/logs/webcache3/opmizer1/cache.pid
> 
> 
> workers 2
> cpu_affinity_map process_numbers=1,2 cores=1,3
> 
> cache_dir rock /accerater/webcache3/storage/rock1 2646 min-size=4096
> max-size=262144 max-swap-rate=250 swap-timeout=350
> cache_dir rock /accerater/webcache3/storage/rock1 2646 min-size=4096
> max-size=262144 max-swap-rate=250 swap-timeout=350

You are telling Squid to start two controllers to the database file
/accerater/webcache3/storage/rock1 from *each* worker. There is zero
benefit from this and the two controllers may enounter collisions as
they compete for acces to the disk without sharing atomic locks. That
leads to cache corruption.

Remove one of those two lines.


> 
> if ${process_number} = 1
> 
> cache_swap_state /accerater/logs/webcache3/opmizer1_swap_log1

Dont use cache_swap_state.

> access_log stdio:/accerater/logs/webcache3/opmizer1_access.log squid

Use this instead (mind the wrap):

access_log
stdio:/accerater/logs/webcache/opmizer${process_number}_access.log squid

> cache_log /accerater/logs/webcache3/opmizer1_cache.log


Use this instead:

cache_log /accerater/logs/webcache3/opmizer${process_number}_cache.log

> cache_store_log stdio:/accerater/logs/webcache3/opmizer1_store.log

You should not need cache_store_log at all.

Either remove it or use this instead (mind the wrap):

cache_store_log
stdio:/accerater/logs/webcache3/opmizer${process_number}_store.log


> url_rewrite_program /accerater/webcache3/media/mediatool/media2
> store_id_program /accerater/webcache3/media/mediatool/media1

Why do you have different binary executable names for the two workers
helpers?

If they are actually different, then the traffic will have different
things applied randomly depending on which worker happened to accept the
TCP connection. If they are the same, then you only need to define them
once and workers will start their own sets as needed.


> unique_hostname fast_opmizer1
> snmp_port 3401

Use this instead:

 unique_hostname fast_opmizer${process_number}
 snmp_port 340${process_number}


All of the above details can move up out of the per-worker area.


> 
> #cache_dir rock /accerater/webcache3/storage/rock1 2646 min-size=4096
> max-size=262144 max-swap-rate=250 swap-timeout=350
> 
> cache_dir aufs /accerater/webcache3/storage/aufs1/${process_number} 5200
> 16 64 min-size=262145
> 
> else
> 
> #endif
> 
> 
> if ${process_number} = 2
> 
> 
> cache_swap_state /accerater/logs/webcache3/opmizer2_swap_log
> access_log stdio:/accerater/logs/webcache3/opmizer2_access.log squid
> cache_log /accerater/logs/webcache3/opmizer2_cache.log
> cache_store_log stdio:/accerater/logs/webcache3/opmizer2_store.log
> url_rewrite_program /accerater/webcache3/media/mediatool/media4
> store_id_program /accerater/webcache3/media/mediatool/media3
> unique_hostname fast_opmizer2
> snmp_port 3402
> 

Same notes as for worker 1.


> #cache_dir rock /accerater/webcache3/storage/rock2 2646 min-size=4096
> max-size=262144 max-swap-rate=250 swap-timeout=350
> 
> cache_dir aufs /accerater/webcache3/storage/aufs1/${process_number} 5200
> 16 64 min-size=262145
> 
> endif
> 
> endif
> 
> 
> 
> http_port 127.0.0.1:3220
> http_port 3221 tproxy
> 
> wccp_version 2
> wccp2_router 192.168.2.1
> wccp2_forwarding_method 1
> wccp2_return_method 1
> wccp2_assignment_method 1
> wccp2_service dynamic 80
> wccp2_service dynamic 90
> wccp2_service_info 80 protocol=tcp flags=src_ip_hash priority=240 ports=80
> wccp2_service_info 90 protocol=tcp flags=dst_ip_hash,ports_source
> priority=240 ports=80

Both workers are telling the WCCP router in different packets that they
are available on the same IP:port. In theory that should work fine,
since the router is just getting twice as many updates as it needs to
keep the proxy registered. In practice some people are finding that
certain routers cant cope with the extra registration operations.


> 
> tcp_outgoing_address 192.168.2.2
> 

Be aware that TPROXY spoof the client outgong address. This line has no
effect on the TPROXY intercepted traffic. Only the traffic received on
port 3220 will be using this outgoing address.
 Your WCCP rules need to account for that by not depending on the packet
IP addresses.


Amos