Table of Contents Previous Next PDF


Setting Up the Network for a Distributed Application

Setting Up the Network for a Distributed Application
This topic includes the following sections:
Configuring the Network for a Distributed Application
A distributed application is an application that runs on multiple computers, each of which supports an installation of the Oracle Tuxedo system. These computers are connected and can communicate with each other through a network that includes hardware, software, access methods, and communication protocols. The Oracle Tuxedo system encodes, routes, and decodes messages, and uses the network to ship those messages between machines. The system performs these tasks automatically.
To configure the networking functionality required to support a distributed application, include the following entries in the configuration file of Table 12‑1.
 
MODEL (Required)
MP. This parameter enables all other networking parameters. It is used only for networked machines. SHM is used for a single-machine configuration, even if the machine is a multiprocessor.
OPTIONS (Required)
LAN (Local Area Network) to indicate that communication will take place between separate machines, rather than between separate processes on the same machine.
MAXNETGROUPS (Optional)
Designate a limit on the number of NETGROUPS that can be defined. The default is 8; the upper limit, 8192.
TYPE=string (Optional)
Determine whether encoding is required when messages are exchanged by two machines. The TYPE parameter specifies the data representation being used on each machine being defined. If a message is being sent from a machine on which one type of data representation is being used to a machine on which a different type of data representation is being used, the message to be sent must be encoded before transmission and decoded upon arrival.
CMPLIMIT=remote[, local] (Optional)
Specify the compression threshold, that is, the minimum byte size for a message to be compressed before being sent to a remote and/or local destination. The value of both remote and local is a number between 0 and MAXLONG. If CMPLIMIT is set to only one value, it is assumed that the specified value is the remote argument and that messages sent to local destinations are never compressed.
For example, if you set CMPLIMIT=1024, than any message greater than 1024 bytes bound for a remote location is compressed.
Compression thresholds can also be specified with the variable TMCMPLIMIT. See the discussion, in tuxenv(5), about the variable TMCMPPRFM, which sets the degree of compression in a range of 1 to 9.
NETLOAD=number (Optional)
Add an application-specific number to the value of LOAD for a remote service. The result is used by the system to evaluate whether a request should be processed locally or sent to a remote machine. A higher NETLOAD results in less traffic being sent to a remote machine.
NETGROUPS (Optional)
NETGROUP (Required)
NETGRPNO=number (Required)
NETPRIO=number (Optional)
Assign a priority to a NETGROUP. This parameter helps the system determine which network connection to use. The number must be between 0 and 8192. Assign a higher priority to your faster circuits; give your lowest priority to DEFAULTNET.
NETWORK (Optional)
LMID (Required)
NADDR=string (Required)
Specify the listening address for the BRIDGE process on this LMID. There are four valid formats for specifying this network address. See the NETWORK section of UBBCONFIG(5) for details.
NLSADDR=string (Required)
Specify the network address for the tlisten process on this LMID. Valid formats are the same as the valid formats for NADDR.
NETGROUP=string (Optional)
Specify a NETWORK group name. The value of string must be a group name specified in the NETGROUPS section. The default is DEFAULTNET.
How Data Moves Over a Network
In a distributed application, data is sent across the network as follows:
At the sending end—the BRIDGE sends a message to destination_machine by writing the message to a virtual circuit and delegating, to the operating system, responsibility for sending it. The operating system retains a copy of every pending message. If a network error occurs, however, pending messages are lost.
At the receiving end—the BRIDGE process listens on a particular network address for incoming messages.
How Data Moves Over Parallel Networks
In a distributed application there are several advantages to using parallel data circuits for sending data across the network:
By listening at more than one address, the BRIDGE achieves higher availability.
By sending data simultaneously on parallel data circuits, the BRIDGE can achieve a higher throughput, if the network was the limiting factor before.
When you configure parallel data circuits, the software does not necessarily fail to deliver a message if the original destination circuit is busy. The system attempts to schedule traffic over the circuit with the highest network group number (NETGRPNO). If this circuit is busy, the traffic is automatically scheduled over the circuit with the next (that is, the second highest) network group number. When all circuits are busy, data is queued until a circuit is available.
Before making a decision to use parallel data circuits, however, you should determine whether it will be important, in your application, for messages to be kept in sequence. The system guarantees that conversational messages are kept in the correct sequence by binding the conversation connection to one particular data circuit.
If your application will require all messages to be kept in sequence, you must program the application to keep track of the sequence for nonconversational messages. If you are using this approach, you may not want to configure parallel data circuits.
Figure 12‑1 describes how data flows when one machine tries to contact another. The figure is based on a sample scenario involving two machines: machine A and machine B. First, the BRIDGE identifies the network groups that are common to both machines: the MAGENTA_GROUP, the GREEN_GROUP, and the DEFAULTNET.
Data flows in parallel on network groups with the same priority (that is, groups for which the same value is assigned to the NETPRIO parameter). Network groups with different priorities are used for failover.
Figure 12‑1 Flow of Data over the BRIDGE
 
 
 
Example of a Network Configuration for a Simple Distributed Application
The following example shows how to configure a simple network:
# The following configuration file excerpt shows a NETWORK
# section for a 2-site configuration.

*NETWORK
SITE1 NADDR="//mach1:80952”
NLSADDR="//mach1:serve"
#
SITE2 NADDR="//mach386:80952"
NLSADDR="//mach386:serve"
How Failover and Failback Work in Scheduling Network Data
Data flows over the highest available priority circuit. If all network groups have the same priority, data travels over all networks simultaneously. If all circuits at the current priority fail, data is sent over the next lower priority circuit. This process is called failover. When failover occurs, the failed connections are retried periodically.
When higher priority network connections are reestablished, failback occurs and no further data is scheduled for the lower priority connection. The lower priority connection is disconnected in an orderly fashion.
If attempts to connect to all network addresses have been made and have failed, new attempts to connect are made the next time application or system data needs to be sent between machines.
Example Configuration of Multiple Netgroups
The hypothetical First State Bank has a network of five machines (A-E). These machines are configured in four network groups and each machine is used in two or three groups.
Note:
The hardware and system software prerequisites for configuring multiple network groups (NETGROUPS) are beyond the scope of this document. For example, machines are frequently required to belong to more than one physical network. Each TCP/IP symbolic address must be identified in the /etc/hosts file or in the DNS (Domain Name Services).
In the following example, it is assumed that in addresses written in the form //A_CORPORATE:5345, the string A_CORPORATE is specified in the /etc/hosts file or in DNS.
The four groups in the First State Bank network include:
DEFAULTNET (the default network, which is the corporate WAN)
BLUE_GROUP (a LAN)
GREEN_GROUP (a private LAN that provides high-speed, fiber, point-to-point links between member machines)
All machines belong to DEFAULTNET (the corporate WAN). In addition, each machine is associated with either the MAGENTA_GROUP or the BLUE_GROUP. Finally, some machines in the MAGENTA_GROUP also belong to the GREEN_GROUP. Figure 12‑2 illustrates group assignments for the network.
Figure 12‑2 Example Network Groups
 
In this example, machines A and B have addresses for the following:
DEFAULTNET (the corporate WAN)
Machine C has addresses for the following:
DEFAULTNET (the corporate WAN)
Machines D and E have addresses for the following:
DEFAULTNET (the corporate WAN)
Because the local area networks are not routed to all locations, machine D (in the BLUE_GROUP LAN) may contact machine A (in the GREEN_GROUP LAN) only by using the single address they have in common: the corporate WAN network address.
Configuration File for the Sample Network
To set up the configuration described in the preceding section, the First State Bank administrator defines each group in the NETGROUPS and NETWORK sections of the UBBCONFIG file as follows:
*NETGROUPS

DEFAULTNET NETGRPNO = 0 NETPRIO = 100 #default
BLUE_GROUP NETGRPNO = 9 NETPRIO = 200
MAGENTA_GROUP NETGRPNO = 125 NETPRIO = 200
GREEN_GROUP NETGRPNO = 13 NETPRIO = 300

*NETWORK

A NETGROUP=DEFAULTNET NADDR="//A_CORPORATE:5723”
A NETGROUP=MAGENTA_GROUP NADDR="//A_MAGENTA:5724"
A NETGROUP=GREEN_GROUP NADDR="//A_GREEN:5725"
B NETGROUP=DEFAULTNET NADDR="//B_CORPORATE:5723"
B NETGROUP=MAGENTA_GROUP NADDR="//B_MAGENTA:5724"
B NETGROUP=GREEN_GROUP NADDR="//B_GREEN:5725"
C NETGROUP=DEFAULTNET NADDR="//C_CORPORATE:5723"
C NETGROUP=MAGENTA_GROUP NADDR="//C_MAGENTA:5724"

D NETGROUP=DEFAULTNET NADDR="//D_CORPORATE:5723"
D NETGROUP=BLUE_GROUP NADDR="//D_BLUE:5726"
E NETGROUP=DEFAULTNET NADDR="//E_CORPORATE:5723"
E NETGROUP=BLUE_GROUP NADDR="//E_BLUE:5726"

Assigning Priorities for Each Network Group
Assigning priorities appropriately for each NETGROUP enables you to maximize the capability of network BRIDGE processes. When determining NETGROUP priorities, keep in mind the following considerations:
If all circuits at the current priority fail, data is sent over the next lower priority circuit.
The default value of NETPRIO is 100.
Example Assignment of Priorities to Network Groups
Figure 12‑3 shows how the First State Bank administrator assigns priorities to the available network groups.
Figure 12‑3 Assigning Priorities to Network Groups
The following priorities are assigned:
Example NETGROUP and NETWORK Sections
The lowest priority among network groups is reserved for the default network group, that is, the group that is not used unless all others are unavailable. Therefore, if you want to limit the use of a particular network, such as a satellite link for which per-minute fees are incurred, designate that network as the default network group.
You can assign a network priority to the default network group by setting the NETPRIO parameter for DEFAULTNET just as you do for any other group. If you do not specify a priority for DEFAULTNET, a default of 100 is used, as shown in the following example:
*NETGROUP
DEFAULTNET NETGRPNO = 0 NETPRIO = 100
For DEFAULTNET, the value of the network group number (NETGRPNO) must be zero; any other number is invalid. The value of NETGRPNO must be unique for each entry.
On the other hand, the same value of NETPRIO may be assigned to multiple network groups. For example, in the First State Bank configuration file, the same network priority (NETPRIO=200) is assigned to both the MAGENTA_GROUP and the GREEN_GROUP.
Each network address (NETWORK) is associated by default with the DEFAULTNET network group. This parameter may be specified explicitly for either of two reasons: to maintain uniformity among entries, or to associate the network address being defined with a second network group.
*NETWORK
D NETGROUP=BLUE_GROUP NADDR="//D_BLUE:5726"
 

Copyright © 1994, 2017, Oracle and/or its affiliates. All rights reserved.