logo
Contact us l Site Map
Login
News & Events : We started our Organisation targetting small scale clients and we are getting better everyday.
Services
Technology Vision Services
Virtualization
Open Source Implementation
Systems Integration
Enterprise Application Integration
Consulting
Training
Technology Forum
 

HP NonStop™ TUXEDO

The HP NonStop™ TUXEDO enables the development of scalable,fault-tolerant OLTP applications that are portable and that interoperate with generic TUXEDO installations on many industry standard platforms. HP NonStop Tuxedo is the proven platform for simplifying distributed transaction processing and message-based application development, while delivering unlimited scalability and standards-based interoperability, which is fundamental to service-oriented architecture.

NonStop TUXEDO Architecture

Because NonStop TUXEDO is targeted specifically for the Himalaya platform, general portability is not a requirement. Hence NonStop TUXEDO is internally modified to adapt to Whereby several identical server processes read from a single request queue. The weighting is user configurable, and allows for differences in the "capacity" of each machine to be taken into account (e.g. the relative network bandwidth between the client machine and each possible server machine, the class of each server machine (workstation, mainframe), etc). Portability" in this case refers to the NonStop TUXEDO system software itself. Portability at the application level is unaffected, the externals of NonStop TUXEDO are equivalent to those of and exploit the unique attributes of the underlying Himalaya hardware and software infrastructure.

The main differentiating characteristics of Himalaya systems (in this context) are as follows:

  • The Himalaya processors are loosely-coupled MP machines, which have very different characteristics to SMP machines:

  • Each machine ("node" in Tandem terminology) can have up to 16 cpus.

  • Each cpu has its own memory. Memory can only be shared by processes in the same cpu

  • Up to 255 nodes can be clustered (using the Tandem Expand networking architecture).

  • Any cpu in a cluster can access any device attached to any other cpu in the cluster (for example, all disks in the cluster are directly accessible from any process on any cpu).

  • Processes send messages to each other via the NonStop Kernel Message System. Any process in the cluster can communicate with any other process in the cluster. The location of the target process is transparent to the caller.

  • A node has a single-system image (SSI), the fact that a node comprises many cpus is transparent to users and application processes.

  • Unlike BEA TUXEDO, NonStop TUXEDO is built upon an operating system and subsystem infrastructure that is explicitly designed to support the needs of OLTP applications. This same infrastructure is used to support Tandem RMs (for example, NonStop SQL/MP (RDBMS), Enscribe (ISAM file system)), and Pathway. Hence, many internal functions which BEA TUXEDO has to provide to make up for the generalities of Unix, are provided by underlying services, and are not required in the NonStop TUXEDO implementation. These underlying services comprise primarily the following components:

  • NonStop Transaction Manager/MP. Provides the transaction management services necessary to associate requests made to RMs with the appropriate transaction, and to coordinate completion (commit/rollback) of the transaction across all RMs involved. Performs transaction recovery processing in the event of failure. Provides transaction and data logging services both for itself (the TM) and RMs.

  • NonStop TM/MP is tightlyintegrated with the NonStop Kernel message system, and the RMs.

  • NonStop Transaction Services/MP. Performs server process management - the services necessary to ensure application server processes are always available to clients (detect server failures and automatically restarts them). Ensures server processes are efficiently utilised by load-balancing client-requests among them.

  • NonStop Kernel Message System. Used to communicate between processes. Provides transparency of target process location (same cpu, node, or across nodes). Automatically propagates transaction information with the message (the receiving process is "infected" with the transaction currently associated with the sending process).

Shared Memory

On Himalaya machines, memory may only be shared between processes in the same cpu. If the BEA TUXEDO architecture were maintained, this would constrain execution of all NonStop BEA TUXEDO (in terms of use, programming, interoperability, and administration). Himalaya clusters may consist of up to 4080 cpus (255*16), hence the term "Massively Parallel Processors" (MPP) is often used to describe these configurations. TUXEDO client, server, and system processes to only a single cpu. Obviously this would yield poor performance and availability so this constraint has to be removed. The "simplest" solution is to simply have a cpu equal a TUXEDO machine, and replicate every shared-memory data-structure on every cpu. But such an implementation would have serious shortcomings also - it would be difficult to configure and manage (every cpu would require an entry in the UBBCONFIG *MACHINES section), and would still offer poor performance (for example, servers in an MSSQ-set could not be distributed across cpus).

The actual solution implemented is as follows:

  • The BB and BBL are replicated across every cpu. This enables clients and servers to be located on any cpu (a necessity), without requiring rework of large tracts of BEA code.Since during normal operation there is little change to the global part of the BB, the overhead of propagating such changes to multiple copies of the BB is not considered a problem.

  • The Global Transaction Table (GTT) is deleted (see Transaction Management section below for details).

  • This architecture maintains the key attribute that a single Himalaya node appears equivalent to TUXEDO machine, preserving BEA TUXEDO externals (in terms of configuration and runtime administration).

Interprocess Messages

The NonStop Kernel message system is used for all NonStop TUXEDO interprocess communication. Because the message system spans all cpus and nodes in a cluster seamlessly, whether the destination process is on the same cpu, same node, or remote node is transparent to the caller and recipient. This contrasts with the Unix message system which is limited to within a single machine (hence the need by BEA TUXEDO for Bridge processes, to logically extend the Unix message system across machines). NonStop TUXEDO is therefore able to do away with Bridge processes completely.

Because the message system spans cpus, NonStop TUXEDO has no constraints on server instance co-location with its "message queue", and hence server processes in a server class (MSSQ-set) may be distributed across cpus.

Transaction Management

NonStop TUXEDO replaces the BEA TUXEDO transaction manager function with NonStop TM/MP. As a result, the GTT is not required (NonStop TM/MP has its own internal datastructures), neither is the functionality of the TMS. So the GTT and the TMS processes are deleted in NonStop TUXEDO.

NonStop TM/MP functionality is tightly integrated with the message system and the RMs. Transaction creation, propagation, and commitment, is a fundamental function of the NonStop Kernel infrastructure. NonStop TM/MP processes exist on each node in the cluster, and manage all the recoverable resources (RMs) on that node. There is no notion of separate groups for each RM, each with its own TMS process, as with BEA TUXEDO.

Beginning a NonStop TUXEDO transaction starts a NonStop TM/MP transaction, and associates the process with that transaction. When the process (client) sends a request to a server (via tp*call(), tpconnect(), or tpforward()), the message system propagates the NonStop TM/MP transaction to the server process. All work done in the server process (for example, RM Since all these processes need access to the BB shared-memory data-structure. Minimum change to BEA code is a high-priority design requirement. access) is then associated with that transaction. When the client commits the transaction, NonStop TM/MP broadcasts the 2-pc sequence to all nodes in the cluster. NonStop TM/MP on each node then interacts with the local RMs to prepare and commit/rollback any changes made on that node on behalf of the transaction.

A key difference in this NonStop TM/MP to RM interaction compared with the BEA TUXEDO to RM interaction, is that NonStop TM/MP acts both as a "global transaction coordinator", and "RM local transaction coordinator" simultaneously (logically NonStop TM/MP provides the function of both the TM and RM roles as defined by the XA interface). NonStop TM/MP provides a single "common" transaction log per node, which is used to save all the necessary transaction recovery information for both NonStop TM/MP and the RMs. A single synchronous log write per node occurs at transaction commitment, irrespective of the number of RMs involved in the transaction. For example, if a NonStop TUXEDO service routine updates a NonStop SQL/MP file, and an Enscribe file, and a Queue file, all the information necessary for recovery is logged with a single synchronous write.

Process Management

In NonStop TUXEDO, process management is performed by NonStop TS/MP. NonStop TUXEDO servers are implemented as NonStop TS/MP server classes (the internal use by NonStop TUXEDO of NonStop TS/MP server classes is transparent).10 A server class may consist of a single server process, or many (if the servers are defined as an MSSQ-set). NonStop TUXEDO administration commands such as tmboot and tmshutdown are transformed (internally) into NonStop TS/MP commands to start and stop server classes.

NonStop TS/MP is responsible for server failure detection and restart. The BEA TUXEDO server process "surveillance" mechanism is replaced by the NonStop TS/MP mechanism. This is considerably different to the BEA mechanism because of the "OLTP optimised" nature of the NonStop Kernel operating system. In this case, the feature of note is that any process can request notification upon the occasion of certain events (for example, on the abnormal death of another process, or upon cpu failure). NonStop TS/MP11 receives such notification for any server process in a server class which abends, and will automatically restart the failed server. If NonStop TS/MP receives notification that a cpu has failed, then it will automatically restart all the server processes from the failed cpu on another cpu.

In BEA TUXEDO, for request-response servers, the number of server instances is static. For NonStop TUXEDO, NonStop TS/MP supports the notion of dynamic servers, which provides an automatic response to increased load. The administrator can configure the MIN and MAX number of instances of a particular server. When the server is first booted, NonStop TUXEDO will start MIN instances of the server in the server class. If queuing starts to occur at the

Load Balancing

There is a mapping made (in the BB) between the service name requested, and the server class name of the server(s) offering that service.12 The server class name is thus obtained from the BB and used to address the message.

In the case of a service offered only by a single-server server class, client requests are sent directly to the server process (where queuing occurs if necessary). No load balancing is required.

In the case of a service offered by a multiple-server server class, load balancing between servers in the server class is performed by NonStop TS/MP, via a distributor-server (there is a separate distributor-server for each server class).13 Logically, the distributor-server represents the single queue in an MSSQ-set to which all client requests are sent, and the servers in the server class are single servers each with their own queue, to which the distributor-server forwards the request. When the server replies, the reply is routed via the distributor-server back to the client. Because it handles all client requests and replies, the distributor-server "knows" precisely the current state of all server processes in the server class (busy, idle, suspended, etc), and hence can perform accurate load-balancing when forwarding the request (to an idle server). Queuing occurs at the distributor-server if necessary (for example, if all the servers in the server class are busy).

If a service is offered by more than one server class, NonStop TUXEDO will select the server class using the same round-robin algorithm as used by BEA TUXEDO when the same service is offered by servers on different machines (selection of the server instance within the server class then occurs via NonStop TS/MP as described above). This mapping is derived from information defined in the UBBCONFIG file. In NonStop TUXEDO, the *SERVERS RQADDR parameter specifies the server class name. The distributor-server is implemented as a process-pair.

NonStop TUXEDO Advantages vs. BEA TUXEDO (on a Unix SMP)

BEA TUXEDO does an excellent job of bringing OLTP-capability to Unix based applications and databases. However, it is somewhat limited by the shortcomings of the Unix SMP environment itself, and by the constraints imposed to achieve portability across multiple Unix implementations and hardware platforms. Because NonStop TUXEDO is specifically designed to run only on Himalaya systems, and has been modified to adapt to and exploit the OLTPoptimised system infrastructure (as described above), the result is a NonStop TUXEDO implementation which exhibits additional benefits over BEA TUXEDO running on a Unix SMP. These benefits accrue in the following areas:

  • Application availability.

  • Performance and scalability.

  • Administration.

Availability

NonStop TUXEDO applications offer higher levels of availability for the following reasons:

  • Fault-tolerance of the underlying hardware.

Because of the replication of components, and their isolation (for example, separate memoryper cpu), no single point of failure will render an entire Himalaya machine unavailable. Failure of a cpu or its memory only affects those processes running in that cpu, no single hardware error could occur which would make NonStop TUXEDO services on a node completely unavailable.

NonStop Tuxedo Components
Eai vision LLC.
img
 
Technology Vision | Services | Consulting | Training | Technology Forum
2007 - 2010 Eaivision LLC. All rights reserved Rss Feed