[isapros] Re: Web Proxy with NLB - Back to basics!
- From: "Thomas W Shinder" <tshinder@xxxxxxxxxxx>
- To: <isapros@xxxxxxxxxxxxx>
- Date: Mon, 14 Jul 2008 08:46:45 -0500
Ah, good point. Too early in the morning. You're right about that.
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:59 AM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: Web Proxy with NLB - Back to basics!
Really?
Also, I thought RR DNS was the preferred option for Firewall clients?
From memory, there are issues with the firewall client and NLB as here:
http://technet.microsoft.com/en-us/library/cc302674.aspx
Firewall Client Connections Fail
Issue: When you add a computer to the ISA Server array, remove a
computer, or restart the NLB service, connections are redistributed
among the array members. When this occurs, connections from a Firewall
client may fail.
Cause: The Firewall client control channel is established with a
specific ISA Server array member, and all Firewall client communication
must be handled by the same array member to succeed. When connections
are redistributed, the Firewall client communication is likely to be
handled by an array member that does not handle the control channel, and
the connection will fail.
Solution: If the connection is associated with a specific application,
close and open the application. If it is associated with a service,
restart that service.
Just to make it more confusing! J
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx]
On Behalf Of Thomas W Shinder
Sent: 14 July 2008 13:53
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
________________________________
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.
________________________________
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.
________________________________
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:
