There is also the consideration of whether you are only load balancing
witango servers or web servers as well. You can have one webserver
(apache/IIS) running with any number of witango servers in a load
group, and you can also have multiple webservers and multiple
witangos. You can have as many webservers as you do witango servers,
but not more.
The configuration of 1 webserver to many witango servers is simpler to
configure but does leave you with a single point of failure. If you
one webserver fails, your witango group will NOT receive requests. If
a witango server fails, the group should then not send requests to the
bad witango server, as you would expect, and as Mr. Schubert has
confirmed. However, you should be aware that it doesn't always work.
If you have a hardware failure on a witango machine, it will work, the
others will work fine. If one witango machine crashes hard, you should
also be fine, but there is a state that witango servers can get into,
where they crash in a way that just HANGS, and doesn't recover, and in
this state, they can act to the group like they are ready for
requests, but instead just hang on every request, and the witango
process on this server must be killed. In every witango installation I
have worked on, this will happen, and you should prepare for it. I
have worked on systems where this happened all of the time, and then
after working with them did it very rarely. This is done by looking at
the tafs and code and looking for certain methods and algorithms that
after much experience you find can have a greater tendency to put
witango into this state. An example is a heavy use of certain types of
external actions. These can get witango in this state, which you want
to avoid.
Another issue to consider is that even though witango should fail
over, and also in those moments where you must kill a witango process
if it hangs, any sessions on that witango system will also be lost.
This means that the users on that system will lose their shopping
carts or whatever other user variable sessions you have going.
Something to keep in mind.
If you go to a many webserver - many witango configuration to
eliminate the single point of failure for the web services, you will
have to employ some form of DNS load balancing. The simplest being
round robin dns. Round robin is great, but requires human intervention
to remove a dns entry if a webserver goes down, and a few mins to
propogate depending on the record's time to live. This is usually ok,
because web servers RARELY go down. There are other options like
hardware or software load balancing that can be setup to failover
without intervention.
--
Robert Garcia
President - BigHead Technology
VP Application Development - eventpix.com
13653 West Park Dr
Magalia, Ca 95954
ph: 530.645.4040 x222 fax: 530.645.4040
rgar...@bighead.net - rgar...@eventpix.com
http://bighead.net/ - http://eventpix.com/
On Oct 20, 2009, at 7:41 AM, Brian Humes wrote:
Hi all,
I have a web server (Windows Server 2003 R2, IIS 6, Witango 5.5
Standard, MS SQL Server 2005) that is serving a lot of traffic. We
think its time to add a second server. Here's what we'd like to
accomplish:
1) When both servers are running, balance the load so each server is
getting roughly half the traffic.
2) If one server goes down for some reason, automatically shift all
traffic to the good server.
3) When a user hits one server, they stay on that server until the
session is completed (I think Witango does this automatically?).
I've gone through the server installation documentation and found
nothing about making this work. I did do some searching through the
archives and found that Witango is (it seems) capable of this, I
just don't know how to do it.
Could someone please point me in the right direction? Any help would
be greatly, greatly appreciated. Thanks!
Brian Humes
Director, Interactive
JohnsonRauhoff
269-428-9257 (direct)
269-428-3377 (main)
269-428-3312 (fax)
www.johnson-rauhoff.com
bhu...@johnson-rauhoff.com
________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
