[isapros] Re: Array Member Failover
- From: "Jason Jones" <Jason.Jones@xxxxxxxxxxxxxxxxx>
- To: <isapros@xxxxxxxxxxxxx>
- Date: Fri, 26 May 2006 22:48:33 +0100
Ah ha...maybe we are getting somewhere and raises another question I
have been asking elsewhere. Looking at the results returned in the
wpad.dat file, the array members are all listed by IP addresses not
FQDN's and are shown individually for each server. The array name is
defined within the array config and this works just fine for the
firewall clients in terms of autodetection, so it is not the case this
this is missing.
From what you say, the wpad.dat file should contain a single entry using
the array DNS name? This is currently not the case and maybe the
problem...
Any idea why I would see a different behavior? Prior to installing the
current solution I VM'd the setup and have subsequently checked that
this also lists the server IP's in the wpad.dat file. Kinda thinking
that two installs can't both be horked :-)
-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx]
On Behalf Of Jim Harrison
Sent: 26 May 2006 22:34
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: Array Member Failover
Such is always the case when the customer wants / needs to "go cheap".
RR DNS is your best bet, so long as you bear in mind that the primary
"server" provided by the wpad and wspad scripts are based on the array
name.
The client-side CARP algorithm understands the server names, so you
*must not* "DNS" the server names to any NLB DIPs. Doing so is
guaranteed to increase your intra-array traffic.
-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx]
On Behalf Of Jason Jones
Sent: Friday, May 26, 2006 2:11 PM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: Array Member Failover
Thanks Jim...I see your points and appreciate the feedback.
Normally I *would* have used NLB if the priority was failover, but
couldn't due to other limitations. Kinda hoped the failover
charachetristic of the auto config script would help out in this case.
Guess I was too hopeful :-(
So based upon this, is the unofficial best paractice for ISA clients
that I see mentioned in public forums still valid?
Web Proxy => Autoconfig script (client-side CARP) Firewall Client => RR
DNS SecureNAT => NLB
-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx]
On Behalf Of Jim Harrison
Sent: 26 May 2006 22:02
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: Array Member Failover
I disagree with that help entry for two reasons:
1. WPAD is completely dependent on the client to understand and use the
script correctly 2. WPAD is client-side CARP; IOW, requests for
different destinations
*may* be directed to a different server in the array, depending on *if*
the client uses the algorithm provided (WinHTTP requests *DON'T*) and if
so, *how*.
This is entirely the *wrong* place to create a load -balancing or
fail-over/back system.
We've added some changes to the WPAD so that the client-side CARP
"shares" better than it used to, but I strongly recommend that you *not*
depend on it for failover.
-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx]
On Behalf Of Jason Jones
Sent: Friday, May 26, 2006 1:19 PM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: Array Member Failover
Thanks for the reply Jim - I don't want to disagree, as I repsect your
input and knowledge, but I thought the autoconfig script was designed to
include an element of failvoer in addition to load balacing? Are we
saying that this failvoer is just too basic to actually rely upon?
When I say autoconfig, I mean client-side CARP and based upon ISA help:
ISA Server supports the Cache Array Routing Protocol (CARP). CARP
enhances Web performance by providing both load balancing and
transparent failover for Web proxy browser connections.
As I said, I would love to use NLB, but client limitations with NIC
teaming won't let me! Am I really expecting too much from the auto
config script in the event of server failure?
Cheers
JJ
-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx]
On Behalf Of Jim Harrison
Sent: 26 May 2006 20:49
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: Array Member Failover
WPAD is not designed to provide failover/back.
As you've noticed, this is not going to work.
WPAD is nothing more or less than a "load-spreading" mechanism that
allows the client to use a different ISA for different destinations.
If you want failover/back, use NLB or another traffic-management system.
-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx]
On Behalf Of Jason Jones
Sent: Friday, May 26, 2006 12:42 PM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: Array Member Failover
Cheers Tom - unfortunately closing the browser doesn't seem to fix the
problem...IE still trys to connect to the primary autoconfig defined
server first then eventually use the other array members (after about
20-30 seconds). This behaviour seems to happen repeatedly on all clients
fdor every new URL entered
The only way to fix it is to bring the failed server back online :-(
________________________________
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx]
On Behalf Of Thomas W Shinder
Sent: 26 May 2006 12:18
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: Array Member Failover
Hi Jason,
Not too low brow for me :) This is a common question with a common
non-answer in the public realm.
What you need to do is close all browser windows and open a new one.
Then the client connects to a live server. I've never worked out in
detail why this happens, but it's related to the autoconfig script
processing [hand waving explanation]
Maybe somebody else can chime in with a more detailed explanation.
Bottom line is that you're not going to get completely transparent
failover for Web proxy clients.
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 <http://tinyurl.com/3xqb7> MVP -- ISA
Firewalls
________________________________
From: isapros-bounce@xxxxxxxxxxxxx
[mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jason Jones
Sent: Thursday, May 25, 2006 4:44 PM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Array Member Failover
Hope this question is not too low brow, if so, kick me and I
will move it to isaserver.org for the masses to mull over ;-)
Anyhow, has anything changed with array member failover behavior
in EE with ISA2k4 SP2? I am sure I have never had problems with array
member failovers in the past...
I have recently deployed an SP2 array with several members and
while testing I have noticed that if the server listed as the first
entry defined within the wpad.dat file is unavailable then the browser
delays for quite some time before attempting to connect to other array
members (e.g. working through the server list in the wpad.dat file). It
does seem to get there, but we're talking 20 seconds or so per website.
Once the website is loaded, performance is fine. When using a new URL,
the delays appears again.
Apart from failover, balancing and distr caching seems to be
working well. I know I could be using NLB, but I believe the following
to be good practice:
Web Proxy => Autoconfig script (client side CARP)
FW Client => RR DNS
I am using a generic name of customerarray.domain.com with RR
DNS entries to balance autoconfig requests between array members. This
is the name used in the autoconfig URL.
I know NLB may come to mind as a workaround, but it is hard to
implement as the customer is using NIC teaming at the hardware driver
level to aggregate NICS and provide NIC fault tolerance. NLB and NIC
teaming never play well from what I have experienced :-(
Can someone please define normal behavior for a client that is
using an autoconfig script when array members are unavailable? I kinda
get the feeling the problem is with the browser and not the array, but
not totally sure when IE does with the script in terms of processing...
I've tried looking at wpad.dat caching and caching of bad
proxies, but neither seems to make much difference...
Any ideas?
JJ
All mail to and from this domain is GFI-scanned.
All mail to and from this domain is GFI-scanned.
All mail to and from this domain is GFI-scanned.
Other related posts:
