[isapros] Re: Web Proxy with NLB - Back to basics!
- From: "Thomas W Shinder" <tshinder@xxxxxxxxxxx>
- To: <isapros@xxxxxxxxxxxxx>
- Date: Wed, 16 Jul 2008 08:37:16 -0500
Let's hear the rant about "deep" packet inspection? I think Check Point
copyrighted the term to insure that it had no real meaning outside of
their marketing crapology.
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: Wednesday, July 16, 2008 8:10 AM
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
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 J)
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 J
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 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
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 J).
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
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
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 J
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 J
Any other ideas/thoughts welcome!
Cheers
JJ
Other related posts:
