This feels like it's about clustering ATS servers, not the origins behind it? 
Our design would like something like this:
LOAD BALANCERS --> POOL OF ATS SERVERS --> POOL OF ORIGINS. In our case the 
origin is the application server.

So we would have say an Active/Passive LB Pair as the externally presented 
host. Behind that VIP would be a pool of 3 or more ATS servers (for redundancy) 
and each ATS server would use a POOL of origins.  From the examples I've seen 
it appears that there is an assumption by ATS that the Origin is a VIP, and 
thus its extracted itself from managing a pool of hosts for a single origin?

Additionally I saw that there are mapping configurations for using multiple 
(different) origins. The ATS Server Pool, seems pretty straightforward, but 
specifically I'm trying to find how I would craft a mapping rule such multiple 
origins for the same mapping.

From: Jason Giedymin [mailto:[email protected]]
Sent: Friday, November 18, 2011 9:45 AM
To: [email protected]
Subject: Re: Using Multiple/Redundant Backend Origins

I believe what your looking for is clustering ATS which serve multiple origins 
(in round robin/ etc) manner.

https://cwiki.apache.org/confluence/display/TS/Clustering

There are still some kinks in it but its getting better.

On Nov 18, 2011, at 9:32 AM, Petzel, David wrote:


Hello,
We are currently in the process of evaluating a new http caching solution and 
on that list is Apache Traffic Server. We've been reading through the online 
documentation and have a pretty good feel for the product, however there is one 
item we are a little clear on. It seems that mapping rules always assume a 
one-to-one relationship from host to origin.  We are interested in having 
multiple redundant origins behind a single host. In Varnish they call this a 
director, and I'm trying to understand what the equivalent in ATS would be.

We do understand that we could use a load balancer VIP as the origin to provide 
this functionality,  however if possible we're looking to have the "Caching 
Servers" communicate directly with the origin providers, rather than routing 
through a VIP.

Could someone point me at the appropriate documentation where this is described?

Thanks

Reply via email to