If you’re been an ISA firewall admin for a while, you might recognize the acronym “CARP” (no, I wasn’t thinking of Blue Coat and transposing the middle two letters). CARP stands for the Cache Array Routing Protocol. The purpose of CARP is allow you to cache Web objects only once in a CARP array and not duplicate objects on servers in that array. This “cache an object only once” feature effectively increases the number of objects you can store in cache, since space isn’t wasted by duplicating objects in the distributed cache.
There are two types of CARP — client side and server side. Most people recommend client side CARP because if provides much higher performance than server side CARP. With client side CARP, the client is able to determine which CARP array member is responsible for a FQDN and sends the request directly to that array member. With server side CARP, the request is sent to any member of the array, and the server then becomes responsible for contacting the server responsible for the FQDN, if indeed the server that receives the request isn’t responsible for the FQDN.
In order for client side CARP to work, the client must have access to the autoconfiguration script.
While that’s all well and good, there has been some messaging regarding CARP over the years that suggests that CARP provides a high-availability solution. I have to admit that I’ve been a bit overzealous in the past and said that CARP has some HA capabilities, but that it wasn’t transparent and required users restart their browsers in order to get connected again and that client side behavior is somewhat inconsistent. Making the use of client side CARP for HA a bit of a “CARP shoot” (cf. Jim Harrison).
Nevertheless, many people would like to think that CARP not only extends the amount of available space in your array’s cache, but also provides a transparent HA and load balancing solution.
So, what do we do about HA and load balancing for Web Proxy client requests? Enterprise Edition of the ISA firewall supports both unicast and multicast mode NLB and you can use this for your HA and Load Balancing needs. But, beware and take this advice from Jim Harrison:
Last word on the subject of NLB for FWC or client side CARP traffic :
Just
Don’t
Do
It
CARP wasn’t designed to support HA. As Jim says:
CARP was *NEVER* designed or intended to be HA – only distributed caching.
If you try to use it for anything else, you’ll lose.
Quit trying to make CARP into something it’s not and never will be.
If you want HA, use NLB, but be prepared for the inevitable intra-array traffic increase that this will incur if you enable server-side CARP.
So, you can still have Web Proxy clients and NLB. The question is, how do you configure it? Let’s look at the options:
Configure the client to use autoconfiguration. If you do this, the client will obtain the autoconfiguration script for the ISA firewall array and then perform client side CARP. Client side CARP does not work with NLB, so we can’t use this option
Configure the client to use the autoconfiguration script. This has the same affect was using WPAD for autoconfiguration, so this clearly won’t work either.
Configure the client to use the internal VIP for the Web Proxy server. This should work. The connections from the internal client will be load balanced between the members of the ISA firewall array. Now you have two options:
- Enable CARP
- Disable CARP (the default)
The default setting is to disable CARP. When the Web Proxy clients are load balanced among the Firewall array members, the same Web content will end up being cached on more than one member of the ISA firewall array, since each array member thinks its responsible for the entire FQDN space, unlike the situation when CARP is enabled, where each member of the CARP array takes a portion of the FQDN space. This leads to some wastage of disk space as the same object could be cached on multiple ISA firewalls in the array.
We could enable CARP and allow the members of the array to perform server side CARP. In this case, the client sends a request to the internal VIP on the ISA firewall array and the connection is load balanced to a machine in the NLB array. Since this is random, there is no assurance that the connection request is made to the CARP array member that is responsible for the FQDN in the request. If the connection request goes to a CARP array member that is not responsible for the FQDN, the CARP array member will send the request to the array member that is responsible for the FQDN. Then that array member can return the object from it’s cache, or if the object isn’t in the its cache, it will retrieve the object, place it in it’s cache, and then return it to the CARP array member that requested the object. Then that CARP array member, who wasn’t responsible for the FQDN, returns the information to the client that made the request, and that array member does not cache the information, since it’s not responsible for that FQDN.
This has the potential for creating an over abundance of intra-array traffic so that machines in the CARP array can perform server side CARP.
As Jason Jones and Jim Harrison so aptly put it, you have the following options when it comes to Web Proxy clients:
- If you are primarily concerned with performance:
Web Proxy Client is supported by client side CARP
- If you are primarily concerned with high availability:
Web Proxy Client is supported by NLB (with or without server side CARP)
- If you are primarily concerned with high availability but want to maintain distributed caching:
Web Proxy Client is supported by NLB and server side CARP (accepting additional intra-array traffic)
HTH,
Tom
Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: [email protected]
MVP — Microsoft Firewalls (ISA)