High-Availability & Migration

Question

Hi all,
I am currently working on adapting our software to a high-
availability architecture using Tuxedo and I have runned into
questions to which I cannot find satisfying answers in the
documentation. Can someone help?
To ensure high-availability, we use two equivalent machines, a
master and a backup, each having sufficient capacity to handle
all the load of the system. The bunch of services handling the
operations of the software can therefore run on either or both
machines. However, a specific message processing operation
requires the participation of 3 different servers which, for a
given message, must all be from the same machine (they must the
same network connection on which acks are sent).
The initial idea was to make all servers run on the master
machine with nothing on the backup. Only in the case of failure
would the servers be transfered to the backup machine – using
group or machine migration. Unfortunately, there is some
information I don’t seem to find in the doc ...
1) So far, everything I read on migration indicates that it can
only be performed manually. Is there any way to have Tuxedo do
it automatically? On which conditions?
2) What happens if one server in the group crashes? From what I
understand, it can be restarted up to MAXGEN time within the
GRACE period, but what then? What if it crashes out of lack of
ressources (memory, hard drive), will it be migrated
automatically to the backup machine? And will the other servers
in the group follow?
3) If, instead of using migration, I decide to have all services
running on both machines; how do I prevent a message from
transiting from one machine to another as it is forwarded to the
different servers in the chain?
Anyone had similar problems? Thanks for the answers.

Answer 1

Marcin Kasperski wrote:
To ensure high-availability, we use two equivalent machines, a
master and a backup, each having sufficient capacity to handle
all the load of the system. The bunch of services handling the
operations of the software can therefore run on either or both
machines. However, a specific message processing operation
requires the participation of 3 different servers which, for a
given message, must all be from the same machine (they must the
same network connection on which acks are sent).If I were implementing this, I would just advertise services which embed
machine information in their name. Then:
- the client would call - say - 'mainsvc' - which would be running on
both machines
- mainsvc would determine the machine it runs on and forward the call to
- say 'mainsvc-machine1'
- the rest of the calls would be directed to 'svc2-machine1' and
'svc3-machine1' (the reply from the first call would contain the info
what to call next)
This way, the first call would find the working machine (using the only
available if the second one crashed and one of the two available in the
round-robin method when both work), the rest would be directed to the
machine you need.
Instead of advertising machine-specific service names, you can also take
a look at data dependent routing.Sorry Marcin, but you have just bound your system to specific machines and
will limit scaling. That's a bad thing. A simpler solution is to use Data
Dependent Routing (DDR). This is probably the single most powerful concept
in Tuxedo, and for some reason people rarely exploit it.
By simply having some kind of machine identifier in the request buffer
either native (part of the natural application data) or artificial (a field
added just for doing DDR routing) you have something like a Zip Code (for US
folk) or Postal Code (for the international crowd). Tuxedo analyzes this
data and based on rules in the UBBCONFIG, routes the message to the correct
system. So if the routing field says MACH1, it goes to SVC1 on machine1.
If the routing field says MACH2, it goes to SVC1 on machine3, etc. etc. I
could have 10 machines, and all 10 would by symmetrical in capability, and I
could route to each accordingly.
Part of what makes Tuxedo so neat to work with, is that you can create a
Logical design, develop it, and then deploy it in any number of different
Physical designs. And if you do everything right, the Logical design
remains intact. For example, there is a drug store chain here in the US
that has over 4000 Tuxedo domains, all working together!! Then they have a
central site that mirrors all 4000 individual databases. Get your
prescription filled at one store, and then go to another, and that second
store can access your records from the central site. DDR insures that all
messages get routed to the correct location. (I here there is a brokerage
firm with 10,000 domains!!!)
Check out DDR, it will make your day.
Brian Douglass
Transaction Processing Solutions, Inc.
8555 W. Sahara
Suite 112
Las Vegas, NV 89117
Voice: 702-254-5485
Fax: [phone]
e-mail: [email protected]