[isapros] Web Proxy with NLB - Back to basics!
- From: Jason Jones <Jason.Jones@xxxxxxxxxxxxxxxxx>
- To: "isapros@xxxxxxxxxxxxx" <isapros@xxxxxxxxxxxxx>
- Date: Mon, 14 Jul 2008 10:04:53 +0100
Hi All,
After a bit of debate and some guidance really...I may be a little clumsy
trying to get my thoughts across here, but please bear with me :)
After reading the recent blog post from Yuri/Jim called Understanding By-Design
Behavior of ISA Server 2006: Using Kerberos Authentication for Web Proxy
Requests on ISA Server 2006 with NLB this got me thinking about an old
conundrum that keeps coming up now again in terms of web proxy fault tolerance.
As stated in the above post (and the current best practice I think) it is
recommended to configure web proxy clients to use client-side CARP by way of
the array script. However, client-side CARP is not "NLB aware" and hence the
script contains references which related to the server DIPs and not the NLB
VIPs. Consequently, NLB is merely used to provide fault tolerance and load
balancing for access to the script only. I am aware that the array script
includes a basic form of fault tolerance, but this is not really a "proper"
fault tolerance solution and in my experience is not sufficient for most
customers looking for web proxy availability.
So, based upon this, I understand we have the following options:
(1) Accept the limitations in terms of client-side CARP fault tolerance and
choose performance as the overriding factor
(2) Force web proxy clients to use a manual proxy server definition and
direct requests to the NLB VIP and lose the benefits of client-side CARP in
favour of NLB fault tolerance.
Neither of the above options is ideal in my experience - what do you guys
normally choose/do???
I have also heard talk of a third option where we can use server-side CARP in
conjunction with option 2 above. The downside is that each array member will
now how to process the script on behalf of the client, which adds CPU cycles
per array member. This seems to be a very good compromise to me, but I have
never been that clear on how best to configure this - which network should CARP
be enabled on - Localhost, Internal, or the custom Intra-Array network????
Also, what sort of CPU impact are we looking at here? Is it just a few more %
per array member, or are we talking about needing an extra CPU per array member
to cope with demand?
In my experience, if customers are looking at EE with a view to using NLB fault
tolerance (as many do) then they are a little disappointed with option 1, as in
reality NLB is not really providing the benefits they anticipated. However, the
loss of the CARP is also a bit of a blow if option 2 is chosen. So, option 3
seems to be the only viable "best of both" workarounds?
Apologies if this is a little back to basics, but I am keen to make sure I get
my thinking straight on this one as it keeps coming up and I want to make sure
I gets my ducks in line from now onwards :)
Any other ideas/thoughts welcome!
Cheers
JJ
________________________________
This email and any files transmitted with it are confidential and intended
solely for the use of the individual to whom it is addressed. If you have
received this email in error, or if you believe this email is unsolicited and
wish to be removed from any future mailings, please contact our Support Desk
immediately on 01202 360360 or email helpdesk@xxxxxxxxxxxxxxxxx
If this email contains a quotation then unless otherwise stated it is valid for
7 days and offered subject to Silversands Professional Services Terms and
Conditions, a copy of which is available on request. Any pricing information,
design information or information concerning specific Silversands' staff
contained in this email is considered confidential or of commercial interest
and exempt from the Freedom of Information Act 2000.
Any view or opinions presented are solely those of the author and do not
necessarily represent those of Silversands
Silversands Limited, 3 Albany Park, Cabot Lane, Poole, BH17 7BX.
Company Registration Number : 2141393.
Other related posts:
