[isapros] Re: Web Proxy with NLB - Back to basics!
- From: Jason Jones <Jason.Jones@xxxxxxxxxxxxxxxxx>
- To: "isapros@xxxxxxxxxxxxx" <isapros@xxxxxxxxxxxxx>
- Date: Wed, 16 Jul 2008 14:59:07 +0100
To quote Tom's own words:
There is no clearcut winner. The standard recommendations go as such:
SecureNAT is supported by NLB
Firewall Client is supported by DNS Round Robin
Web Proxy Client is supported by CARP
Whenever you go outside this recommendation, things get murky, messed up and
unsupported :)
Maybe there should be a silent "as long as you don't want proper HA" after the
third item? :)
Maybe this is my problem, as I am reading it knowing it won't really work very
well when HA is part of the solution requirement? And I think this is a fair
assumption for most people...
Given that I am basing this whole discussion on the fact that most people
nowadays want a "reasonably" good form of HA for web proxy clients, I cannot
see that the above recommendation/statement is true anymore (or ever was).
Hence I was looking for a "more realistic" recommendation now that HA is a more
common requirement for web proxy deployments.
Some examples of my confusion:
http://blogs.technet.com/isablog/archive/2008/06/26/understanding-by-design-behavior-of-isa-server-2006-using-kerberos-authentication-for-web-proxy-requests-on-isa-server-2006-with-nlb.aspx
"On a scenario where you are using ISA Server 2006 with NLB and you also want
to use Kerberos for Web Proxy authentication what you should do is use
Automatic Script Configuration
(WPAD<http://technet.microsoft.com/en-us/library/bb794779(TechNet.10).aspx>)."
http://technet.microsoft.com/en-gb/library/bb794741.aspx
"CARP and NLB can be both be enabled on the same network, however, this should
only be done in organizations where browsers use automatic detection or a
configuration script."
After a fair bit of discussion I think a good summary would be:
If you are primarily concerned with performance:
Web Proxy Client is supported by CARP
If you are primarily concerned with high availability:
Web Proxy Client is supported by NLB
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)
Does this seems fair?
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On
Behalf Of Jim Harrison
Sent: 16 July 2008 14:10
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: Web Proxy with NLB - Back to basics!
"everyone keeps recommending it!!" - who?
If you know of a MS doc that says "CARP == HA", gimme link and I'll file the
bug to get it fixed.
This particular point is a long-standing jihad for me that ranks right up there
with "deep packet inspection".
"just scrap client-side CARP altogether and go NLB for WP too if HA is the
primary requirement?
" - yes, absolutely. CARP is a great caching and "kinda-sorta" LB if you hold
your mouth just right, but it should never be considered in the same context as
any form of HA solution.
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On
Behalf Of Jason Jones
Sent: Wednesday, July 16, 2008 12:38 AM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: Web Proxy with NLB - Back to basics!
I'm not, not, not!!!!!!!!! :-P
To quote from my original question ". 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."
I strongly dislike CARP due to the poor HA abilities, but everyone keeps
recommending it!! That is my main issue!!!
Maybe we should just end this, as I am getting more than a little frustrated
and we seem to be going in circles...thanks for all the replies, if nothing
else I now know that my thinking is correct, even if I don't like the answers...
Jason Jones | Security | Silversands Limited | Desk: +44 (0)1202 360489 |
Mobile: +44 (0)7971 500312 | Email/MSN:
jason.jones@xxxxxxxxxxxxxxxxx<mailto:jason.jones@xxxxxxxxxxxxxxxxx>
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On
Behalf Of Jim Harrison
Sent: 16 July 2008 06:09
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: Web Proxy with NLB - Back to basics!
This is getting out of hand.
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.
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On
Behalf Of Jason Jones
Sent: Tuesday, July 15, 2008 8:35 AM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: Web Proxy with NLB - Back to basics!
Totally agree and you actually echo some of my original comments!
Your comment of:
Jim >> When you factor in HTTP request timeout and TCP timeouts, the user
experience for a WPAD-based HA solution ultimately fails to meet the basic
definition of the word "solution"
is exactly what I am getting at...so if we agree on the above being true, what
*is* the best solution, just scrap client-side CARP altogether and go NLB for
WP too if HA is the primary requirement?
I still feel we are being contradictory here, as the standard recommendations
mentioned by Tom provide poor Web proxy HA and yet we still keep coming back to
this recommendation...we also say don't do NLB and CARP yet this is the exact
scenario in the blog post discussing Kerberos authentication for web proxy
clients (unless I am confused :))
At the moment I feel like my only retort for customers is "Microsoft recommends
using CARP for web proxy clients, but actually if you want a HA solution this
option sucks!" :-P
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On
Behalf Of Jim Harrison
Sent: 15 July 2008 14:45
To: 'isapros@xxxxxxxxxxxxx'
Subject: [isapros] Re: Web Proxy with NLB - Back to basics!
..what he said.
As a rule, I strongly, most emphatically discourage dependency on any client
application to provide any form of LB or HA - it's a failure state just waiting
to happen. Contrary to appearances or other misguided article statements,
client-side CARP is not designed to provide LB or HA. The fact that it
provides a list of proxies for a given request indicates only that the ISA dev
team recognized that giving the application choices was a useful thing to do.
The CARP script can exert no influence whatsoever on the consuming
application's behavior in that regard.
Case in point:
Outlook 2003+ is able to connect to Exchange 2003+ using RPC/HTTP. This is
true also of RDP client 6.1 when connecting to TSG. the point here is that
they both have a common code path through WinHTTP. When WinHTTP is configured
for auto-discovery, it imposes a limit that has been documented in MSDN for
quite some time (at least since 2004 from my experience):
http://msdn.microsoft.com/en-us/library/aa383157(VS.85).aspx.
The upshot of this limitation is as follows:
Scenario;
- WinHTTP-based client behind a CERN proxy array (doesn't have to be
ISA or TMG).
- WinHTTP is configured for auto-discovery
- Proxy1 is unavailable to proxy clients, but is responsive to its
peers
1. The WinHTTP client app sends its request to WinHTTP
2. WinHTTP requests and processes the WPAD script
3. The script output lists Proxy1 as the first choice for this request
4. WinHTTP tries to connect, but cannot reach Proxy1
5. WinHTTP connects to Proxy2 and requests the WPAD script
6. (repeat 2-4)
7. WinHTTP connects to Proxy3 and requests the WPAD script
8. (repeat 2-4)
9. WinHTTP connects to Proxy4 and requests the WPAD script
10. (repeat 2-4)
11. ...
Since Proxy1 is responsive to the other array members, the peer status request
sent periodically between array members will include the client-unreachable
proxy in the WPAD script.
The point here is that in spite of your and the ISA dev team's best intentions
and efforts, the client app will be your biggest pain. The ISA dev team did
everything they could from the remote server perspective to give the client all
it needed to make such decisions, but ultimately, it's up to the client app to
behave properly.
When you factor in HTTP request timeout and TCP timeouts, the user experience
for a WPAD-based HA solution ultimately fails to meet the basic definition of
the word "solution".
HTH,
Jim
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On
Behalf Of Thomas W Shinder
Sent: Tuesday, July 15, 2008 4:57 AM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: Web Proxy with NLB - Back to basics!
Hi Jason,
There is no clearcut winner. The standard recommendations go as such:
SecureNAT is supported by NLB
Firewall Client is supported by DNS Round Robin
Web Proxy Client is supported by CARP
Whenever you go outside this recommendation, things get murky, messed up and
unsupported :)
Thomas W Shinder, M.D.
Site: www.isaserver.org<http://www.isaserver.org/>
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7
MVP -- Microsoft Firewalls (ISA)
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On
Behalf Of Jason Jones
Sent: Tuesday, July 15, 2008 2:45 AM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: Web Proxy with NLB - Back to basics!
As ever, thanks for the responses chaps...still not really sure of the best way
forward. I was trying to find a clear winner rather than have to elaborate each
of the possible options for every customer who asks for web proxy fault
tolerance and just end up saying "you choose...". Maybe it just isn't clear
cut...I wish CARP could somehow could be made NLB aware, if this isn't an
oxymoron :)
Not quite sure I get the "Use NLB or CARP but never both" comment as this seems
contradictory to the blog post you did and also what I have read on
www.microsoft.com/isa<http://www.microsoft.com/isa> You also follow up with "if
you're willing to tolerate" e.g. never, unless you want to :-P confused :-S
Jason Jones | Security | Silversands Limited | Desk: +44 (0)1202 360489 |
Mobile: +44 (0)7971 500312 | Email/MSN:
jason.jones@xxxxxxxxxxxxxxxxx<mailto:jason.jones@xxxxxxxxxxxxxxxxx>
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On
Behalf Of Jim Harrison
Sent: 15 July 2008 01:46
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: Web Proxy with NLB - Back to basics!
..so will the CARP proxy client benefit not at all from the use of NLB.
Use NLB or CARP but never both.
If you're willing to tolerate the inevitable increase in intra-array traffic
that will surely result from NLB-based web proxy traffic, then go for #3 (which
was never numbered :)).
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On
Behalf Of Jason Jones
Sent: Monday, July 14, 2008 7:15 AM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: Web Proxy with NLB - Back to basics!
So, chaps...
Is option 3 a workable best of both worlds compromise?
I accept that FWC will need to use a non-VIP configuration.
Please...........:-)
Jason Jones | Security | Silversands Limited | Desk: +44 (0)1202 360489 |
Mobile: +44 (0)7971 500312 | Email/MSN:
jason.jones@xxxxxxxxxxxxxxxxx<mailto:jason.jones@xxxxxxxxxxxxxxxxx>
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On
Behalf Of Thomas W Shinder
Sent: 14 July 2008 15:11
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: Web Proxy with NLB - Back to basics!
Yep, I realized that soon after writing that with my eyes closed :)
Thomas W Shinder, M.D.
Site: www.isaserver.org<http://www.isaserver.org/>
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7
MVP -- Microsoft Firewalls (ISA)
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On
Behalf Of Jim Harrison
Sent: Monday, July 14, 2008 8:49 AM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: Web Proxy with NLB - Back to basics!
You can't use the FWC to gain LB either.
When the FWC connects to the VIP, it'll request the config data from that IP
and will be rewarded with data from a specific server. For the next 6 hours,
the FWC will communicate *ONLY* to that server via the IP derived from
resolving the name inn the FWC settings for that network. If you try to cheat
by configuring the FWC and WP settings so that they refer to the VIP, then you
will enjoy the benefits of a circular traffic flow policy (I demonstrated this
at the MVP summit this year).
Last word on the subject of LB FWC or CARP traffic :
Just
Don't
Do
It
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On
Behalf Of Thomas W Shinder
Sent: Monday, July 14, 2008 5:53 AM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: Web Proxy with NLB - Back to basics!
Hi Jason,
I was thinking of not using CARP at all. Just use the FWC to support load
balancing and failover, and let those connections be cached without CARP. Or
disable caching completely. I often think that caching actually reduces the
overall end user performance perception in many cases, because there just
aren't enough users to reach the numbers required to make caching statistically
significant.
On the other hand, failover and load balancing is always statistically
significant :)
Tom
Thomas W Shinder, M.D.
Site: www.isaserver.org<http://www.isaserver.org/>
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7
MVP -- Microsoft Firewalls (ISA)
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On
Behalf Of Jason Jones
Sent: Monday, July 14, 2008 7:31 AM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: Web Proxy with NLB - Back to basics!
Sorry Tom, didn't quite get this: "In this scenario you can get the advantages
of caching with the Firewall client, and you can take advantage of NLB when
using the firewall client. So, all you lose are some nominal gains conferred
from CARP"
Which scenario/option? - do you mean option 3? If so, which network do you need
to enable it on? Intra-Array "feels" right, but not 100% sure...
Jason Jones | Security | Silversands Limited | Desk: +44 (0)1202 360489 |
Mobile: +44 (0)7971 500312 | Email/MSN:
jason.jones@xxxxxxxxxxxxxxxxx<mailto:jason.jones@xxxxxxxxxxxxxxxxx>
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On
Behalf Of Thomas W Shinder
Sent: 14 July 2008 13:25
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: Web Proxy with NLB - Back to basics!
Hi Jason,
I think you've got the analysis down right. CARP and NLB have never been two
great tastes that taste great together.
In this scenario you can get the advantages of caching with the Firewall
client, and you can take advantage of NLB when using the firewall client. So,
all you lose are some nominal gains conferred from CARP.
Tom
Thomas W Shinder, M.D.
Site: www.isaserver.org<http://www.isaserver.org/>
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7
MVP -- Microsoft Firewalls (ISA)
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On
Behalf Of Jason Jones
Sent: Monday, July 14, 2008 4:05 AM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Web Proxy with NLB - Back to basics!
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:
