| Download Docs | |
|
| bea.com | products | dev2dev | support | askBEA |
|
|
|
 |
| e-docs > WebLogic Java Adapter for Mainframe > Configuration and Administration Guide > Scaling WebLogic JAM Configurations |
|
Configuration and Administration Guide
|
Scaling WebLogic JAM Configurations
WebLogic JAM can be configured to scale as you integration needs grow. WebLogic JAM can also be configured with redundant components that can fail over when a hardware or software system fails. Reliability and scalability are goals of any mission critical application.
the ability of the system to continue functioning under adverse conditions such as server or network outage
the ability of the system to provide acceptable throughput and performance under high volume use.
In support of these mission critical application goals, WebLogic JAM offers the following features:
Connecting to Multiple Regions
The CRM component of WebLogic JAM uses APPC to establish connections to back-end systems. A single CRM can establish multiple CRM Links (APPC connections) to different back-end systems. When a mainframe application is available in multiple back-end systems, the CRM can load-balance service requests between the back-end systems and can failover if a connection to a back-end system is lost.
Figure 4-1 CRM Connection to Multiple Regions
Connecting Multiple Gateways to a Single CRM
WebLogic JAM CRM permits multiple Gateways to connect and use the resources provided by a single CRM process. This feature considerably reduces the processing load required on the computer hosting the CRM while supporting distribution of workload at the WebLogic JAM Gateway level. Configuration of a single CRM is easier than the configuration of multiple CRMs.
Multi-Gateway configuration is common for installations where a number of WebLogic JAM Gateways are hosting resources for a single mainframe. The multiple Gateways provide mainframe to WebLogic load balancing and failover. Figure 4-2 shows multi-Gateway configuration in the WebLogic Server domain.
Note: For more information about support for load balancing and failover in a clustered environment, see Support for a Clustered Environment.
Figure 4-2 Multi-Gateway/Single CRM Scenario
The CRM provides support for multiple, concurrently connected instances of WebLogic Server / WebLogic JAM Gateway. This section provides information about the following topics:
Advantages of Multi-Gateway Support
The primary advantage of Multi-Gateway support is the ability for the CRM to host concurrent connections from one or more WebLogic JAM Gateways. The advantages of this approach include:
For more information about WebLogic JAM support for clustered environment, load balancing, transaction management, and bi-directional failover support, see Support for a Clustered Environment.
Disadvantages of Multi-Gateway Configuration
In a multiple Gateways CRM configuration, the CRM is a single point of failure. To overcome this disadvantage, multiple CRMs and multiple Gateways can be configured to provide more redundancy and reliability to your WebLogic JAM system. This is described further in Clustered Gateways, Multiple CRMs.
Multi-Gateway Connection Issues
The CRM offers a single point of contact - that is, a single listener socket (identified by host IP address and port number) to which components (such as WebLogic JAM Gateways) can address their connection requests. Each new connection request is handed off to a server socket dedicated to servicing that component connection.
Version checking ensures that the CRM supports and is compatible with the WebLogic JAM component. If the component does not meet these requirements, the connection request is rejected. All concurrently connected WebLogic JAM Gateways have equal standing with respect to the CRM, thus making them equal peers.
However, the CRM attaches significance to the following component connect/disconnect scenarios:
First WebLogic JAM Gateway Connection
If the component is a WebLogic JAM Gateway and this is the first (or only) Gateway to connect to the CRM, the CRM accepts configuration information from the WebLogic Administration Console to initialize the VTAM interface and to establish links with mainframe systems, such as CICS and IMS.
When CRM configuration is complete, the client receives a response indicating that the CRM is ready to begin processing requests. This configuration is the common deployment configuration for WebLogic JAM.
For detailed information about configuring connectivity for the CRM, see Step 2: Define Where the CRM Will Run in Configuring WebLogic JAM Connectivity.
Subsequent WebLogic JAM Gateway Connections
If the client is a WebLogic JAM Gateway and there are other Gateways currently connected to the CRM, the client is held in abeyance (if necessary) until CRM configuration is complete. In this case, the first WebLogic JAM Gateway client has already supplied the CRM configuration information and configuration information is not required. If and when CRM configuration is complete, the client receives a response indicating that the CRM is ready to begin processing requests.
Multi-Gateway Disconnect and Shutdown Issues
WebLogic JAM provides support for the following orderly disconnection and shutdown procedures.
Gateway Disconnect
When a WebLogic JAM Gateway disconnects, the CRM continues to service other connected Gateways. When the last (or only) WebLogic JAM Gateway disconnects, the CRM resets its current configuration, disconnecting from any mainframe systems (CICS, IMS) with which it has established connections.
Shutdown Processing (All Gateways Except the Last)
During shutdown, a Gateway disconnects (closes the socket connection), Phase 1 shutdown processing is initiated for that connection only. Phase 1 shutdown is a "shutdown pending" state in which the following is true:
The CRM will not proceed to Phase 2 shutdown processing if other Gateways are still connected. Links to mainframe systems will remain active and the CRM will continue normal processing for other connected Gateways.
Shutdown Processing (Last Gateway)
When the last (or only) Gateway requests shutdown or closes its connection with the CRM, the CRM executes Phase 1 shutdown processing for that Gateway as described in Shutdown Processing (All Gateways Except the Last). However, when Phase 1 shutdown processing is complete, the CRM proceeds to Phase 2 shutdown processing, in which the following occurs:
Note: If and when a connection request is subsequently received from a WebLogic JAM Gateway, the CRM will re-configure itself. For detailed information about CRM startup and shutdown, see CRM Administration.
Understanding Mainframe to WebLogic Load Balancing in a Multi-Gateway CRM
Multi-Gateway support allows several WebLogic JAM Gateways to be concurrently connected to a single CRM. The connected Gateways share a common configuration and hence offer a common set of services. Therefore, a mechanism must exist to distribute mainframe to WebLogic requests (originating on the mainframe) among the available gateways, a technique commonly referred to as load balancing. Normally, the objective of load balancing is to distribute requests for service across the available servers in such a way that serialization is minimized, resource requirements are balanced, and overall throughput is maximized.
Many algorithms exist for scheduling work among multiple processors, ranging from the very simplistic to the very complex. Mainframe to WebLogic requests are always load balanced via the round-robin method.
Mainframe to WebLogic request load balancing is a function of the WebLogic JAM CRM process. The CRM load balances between all connected gateways without regard to their cluster arrangement.
Support for a Clustered Environment
A WebLogic cluster is a group of servers that, from the application point-of-view, operate as a single server. A cluster provides:
additional servers can be added to the cluster dynamically to increase capacity.
redundancy of multiple servers insulates applications from failures
The cluster support for the WebLogic JAM Gateway enables reliable remote access to mainframe services. Clients may run on any machine with network access to the WebLogic Server machine(s) hosting the Gateway and benefit from transparent load balancing and failover features offered by both WebLogic Server and WebLogic JAM.
WebLogic JAM Gateway offers client access to the mainframe service via the Java Remote Method Invocation (RMI) feature of WebLogic Server. RMI access allows WebLogic JAM to take advantage of all the cluster features of WebLogic Server while still maintaining a level of control for enabling/disabling services.
WebLogic JAM provides the following features in a clustered environment:
Clustered Gateways, Single CRM
A scenario of clustered Gateways with a single CRM is recommended for large sites where a number of WebLogic JAM Gateways are deployed to access the resource in a single mainframe. Load balancing and failover are supported for both mainframe to WebLogic and WebLogic to mainframe requests while minimizing mainframe resources used. Figure 4-3 shows clustered multi-Gateway configuration in a WebLogic Server domain.
Figure 4-3 Clustered Gateways/Single CRM Scenario
Clustered Gateways, Multiple CRMs In this environment, multiple WebLogic JAM Gateways are deployed in a cluster, and the Gateways are distributed to two different CRMs. This configuration offers the flexibility to deploy Gateways as required. In this clustered environment, each CRM configuration should be homogeneous, offering the same back-end application services. Multiple CRMs offer additional failover capability if they are connected to the same back-end systems. In this configuration, half of the Gateways are assigned to each CRM to provide maximum redundancy. However, a combination of multiple Gateways to a CRM and single Gateway to a CRM can be combined. Figure 4-4 shows a clustered multi-Gateway configuration in a WebLogic Server domain. Figure 4-4 Clustered Gateways/Multiple CRM Scenario
Load Balancing Support with WebLogic Server The WebLogic Administration Console provides you with the tools to configure WebLogic to mainframe load balancing for WebLogic JAM. Load balancing is one of the primary tools employed in making systems scalable. WebLogic JAM takes advantage of the sophisticated load balancing features of WebLogic clusters for WebLogic to mainframe requests such that all WebLogic to mainframe load-balancing in WebLogic JAM occurs among a group of servers arranged in a WebLogic cluster. When requests are made to remote WebLogic JAM services, load balancing occurs among all WebLogic JAM Gateways in the cluster that offer the service. For additional information on WebLogic Clusters please refer to the WebLogic Server documentation at http://download.oracle.com/docs/cd/E13222_01/wls/docs70/cluster/index.html. Failover Support with WebLogic Server Failover is the ability of a system to detect a service failure and automatically retry the operation using another Gateway. This includes the ability to recover in the event of a server failure and the ability to find another instance of a service on an available server. Under the best of conditions the results of a service are idempotent, meaning that multiple invocations of the service, with the same input, produce the same output with no side effects. An example of an idempotent service would be a currency translation service. The service produces the same output each time it is run for a given input value and it has no side effects. Under these conditions it is safe to failover a request for any type of failure. Failover for WebLogic to Mainframe Services All WebLogic to mainframe services in WebLogic JAM are assumed to be non-indempotent. Non-idempotent services are programs that have effect on external events or that may return a different answer each time they are invoked. An example of a non-idempotent service is a program which produces a check to be mailed to a supplier. If the service fails after producing the check a retry operation would produce a second check. For non-idempotent services failover is only safe if it can be determined that the failure occurred before the service began processing the request. Failover for Mainframe to WebLogic Services A mainframe For detailed information about WebLogic Server failover support, refer to the "Failover Support for Clustered Services" section in the WebLogic Server documentation at http://download.oracle.com/docs/cd/E13222_01/wls/docs70/cluster/index.html.
Support for Distributed Transactions
WebLogic JAM leverages distributed transaction support from WebLogic Server. Transactions allow multiple updates to one or more resources performed with integrity. For example, transferring from one bank account to another.
Note: For information about administering transaction, see Administering Transactions.
WebLogic JAM offers full support for XA distributed transactions allowing resources on WebLogic Server, CICS, and IMS to be enlisted in a single tightly coupled transaction or multiple loosely coupled transactions. Regardless of the origin of a transaction the XA two-phase commit protocol supported by WebLogic JAM ensures the integrity of all resources effected.
In the case of loosely coupled transactions, the local transaction manager treats each transaction as distinct, preventing access to modifications. Although these transactions are loosely coupled, the transaction manager is not aware of the relationship between the multiple transactions.
Transactions, like requests and responses, are implicitly associated with a single CRM client. With multi-Gateway CRM support, all Gateways and regions connected to the CRM participate in the transaction management to ensure a tightly-coupled transaction in the global transaction.
For detailed information about WebLogic Server support for distributed transactions, refer to "Introducing Transactions" in the WebLogic Server documentation at http://download.oracle.com/docs/cd/E13222_01/wls/docs70/jta/gstrx.html.
Transactional Affinity
When a transaction is started in a specific transaction manager or resource manager, then the transaction is referred to as having affinity to those resources. These resources are chosen over all other resources for subsequent requests in order to allow the transaction resources to be tightly-coupled. In the WebLogic JAM distributed transaction, transaction affinity is maintained. This means that within a cluster, WebLogic will try to select the same server instance (and thus the same WebLogic JAM instance) to process all client requests in a transaction. In addition, a CRM will attempt to select the same CRM link to process all client requests in a transaction.
In order to ensure that the same server instance and/or CRM link are selected, then all services that participate in the transaction should be deployed in the same server instance or on the same CRM link. If this is not true, then a different instance or link is selected, and the transaction is said to be loosely-coupled with its resources.
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
