Availability Guide for Application Design

Increasing the Availability of Tuxedo Applications
Availability Guide for Application Design—525637-004
5-13
Design Implications for NonStop Tuxedo
Applications
•
Ensure that your server design is not prone to performance problems that can slow
your application beyond the acceptable limits specified in your company’s business
plans. For example, you should avoid mixing long-running transactions and short
transactions in the same server. The danger of mixing these two transaction types
is that short transactions can be locked out while long transactions are executing.
Response time to the user might be unacceptably long.
•
Ensure that your server process is designed with adequate error-handling
capabilities. Refer to Section 9, Minimizing Programming Errors, for general
information on error handling. Specific to server processes, be sure to respond to
the client or requester with some appropriate information if an error occurs.
Operational Concerns
Consider the following operational concerns when designing a NonStop Tuxedo
application. For information on how to perform related tasks, refer to the NonStop
Tuxedo System Administration Guide.
•
Ensure that the limits set in the configuration file are large enough to permit the
dynamic addition of servers and services.
•
Be sure to configure a list of processors for members of the server class to run in.
Otherwise, all members of a server class run in one processor; if you lose that
processor, you lose the entire server class. Moreover, if a processor failure occurs,
you need alternate processors in the processor list to restart failed static servers.
•
Configure WSL processes with more than one processor. Because the WSL
process runs as a server class, it is restarted in an alternate processor if one is
specified. If the processor in which the WSL process is running fails, connection
attempts by workstation clients fail until the processor is reloaded—unless an
alternate processor is configured.
•
Consider running two WSL processes, possibly using different TCP/IP processes,
TCP/IP addresses, and communications controllers. Then configure the /WS client
with the two WSL network addresses. When the /WS client requests a connection,
if the first address cannot be successfully contacted, then the second will be
automatically tried.
•
Run TCP/IP processes as process pairs.
•
Run the TCP/IP TELNET process as a process pair to ensure that system
management applications can access the NonStop Tuxedo application after a
processor failure.
•
Use the most reliable communications links possible between master and
nonmaster machines.
•
Configure the number of links in the NonStop Tuxedo system to ensure that
workstation /WS clients and native System /T clients will not be denied access to
server processes.