On 30/04/2013 2:49 a.m., Alex Domoradov wrote:
On Mon, Apr 29, 2013 at 4:57 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote:
On 26/04/2013 10:57 p.m., Alex Domoradov wrote:
On Fri, Apr 26, 2013 at 12:31 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx>
wrote:
On 26/04/2013 8:37 p.m., Alex Domoradov wrote:
First of all - thanks for your help.
Problem #1: Please upgrade your Squid.
Squid-2.6 has been 3 years since the last security update, nearly 5
years
since your particular version was superceded.
ok, I will update to the latest version
On 24/04/2013 12:15 a.m., Alex Domoradov wrote:
Hello all, I encountered the problem with configuration 2 squids. I
have the following scheme -
http://i.piccy.info/i7/0ecd5cb8276b78975a791c0e5f55ae60/4-57-1543/57409208/squids_schema.jpg
Problem #2: Please read the section on how RAID0 interacts with Squid
...
http://wiki.squid-cache.org/SquidFaq/RAID
Also, since youa re using SSD, see #1. The older Squid like 2.6 push
*everything* through disk which reduces your SSD lifetime a lot. Please
upgrade to a current release (3.2 or 3.3 today) which try to avoid disk
a
lot more in general and offer cache types like rock for even better I/O
savings on small responses.
ok. The main reason why I choose raid0 is to get necessary disk space
~400
Gb.
It does not work the way you seem to think. 2x 200GB cache_dir entries
have
just as much space as 1x 400GB. Using two cache_dir allows Squid to
balance
teh I/O loading on teh disks while simultaenously removing all processing
overheads from RAID.
If I understood you correctly in my environment will be more
preferable to use something like
SSD1 /dev/sda
SSD2 /dev/sdb
# mount /dev/sda /var/spool/squid/ssd1
# mount /dev/sdb /var/spool/squid/ssd2
and point squid to use 2 separate disk space
cache_dir aufs /var/spool/squid/ssd1 200000 16 256
cache_dir aufs /var/spool/squid/ssd2 200000 16 256
Yes that is the idea.
I see, and on which disks in that case would be place files? It would
be something like round robin?
The default is for each transaction response to be stored on the
currently least loaded directory:
http://www.squid-cache.org/Doc/config/store_dir_select_algorithm/
So you see the packets "exiting" machine A and never arriving on machine
"B". With only a wire between them that is unlikely.
As I said before the firewall has to be getting in the way somewhere. There
are several layers of components involved with the firewall these days and
each end of the link has its own version of the same layers of components.
I'm afraid it is going to be up to you to track down exactly which one is
getting in the way. The best I can do is point you at a few things which are
commonly causing trouble to other Squid users with this type of setup:
* rules in the Squid box capturing the Squid outbound packets and sending
them back to Squid.
* rules on the sending box preventing delivery (DROP/REJECT on outbound)
* rules on receiving box preventing arrivals (DROP/REJECT on inbound).
You focused earlier on the routing rules as evidence that the looping back
to Squid was not happening, but it is both routing rules, and NAT rules
involved can do it. The NAT ones have the nasty property of changing the
packets which can make the NATed packet be missed by monitoring tools
(tcpdump etc). So take extra care there. These are most often the problem as
the slight mistake of omitting or adding a NIC interface or IP range to the
NAT rules can have major effects on what they are capturing.
The DROP rules at both sides could be hidden anywhere in the firewall
complexity. So a full audit is sometimes required to find things hidden
away. Alternatively there are things like rp_filter or SELinux which are
automatic components doing the same things as a DROP rule for certain things
- often without reporting what they are dropping. If something like that is
happening it can be *very* difficult to identify. Good luck if its one of
these.
The one thing you have demonstrated is that the problem is something in the
operating system *outside* of Squid. So this is not really an appropriate
place for detailed tracking any more. The best place if you still need
further help would be the help groups for the developers of the networking
stack on your machine(s). From the tools you've mentioned already I guess
that would be netfilter.
Amos
I see, all I want to know is that is there exist any settings in squid
to avoid such problems without modification routing tables. Something
like parent_tcp_outgoing_address ;)
There is just tcp_outgoing_address. It can use an ACL of type "peername"
to match (or not) the cache_peer traffic.
Amos
