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

johnzeng johnzeng2013 at yahoo.com
Mon Mar 9 12:43:54 UTC 2015


Hello Amos:

----------------------------------------------------------------------------------------------------------------------- 


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.

-------------------------------------------------------------------------

Your meaning is running two different process for wccp redirection and Cache operation ?

first process is for wccp redirection

and other process is for Cache operation


  




于 2015年03月09日 13:01, 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



More information about the squid-users mailing list