Filter
Top Products
Starting and Setting Up RTR
2.2 Setting Up—An Example
Figure 2–1 Configuration Example
F E 1
F E 2
F E 3
T R 1
T R 2
B E 1
B E 2
B E 3
SMM_CONFIG_EX 01−99
F r o n t e n d R o u t e r s ( T R )
B a c k e n d s ( B E )
s ( F E )
In this example, the application client processes run on the nodes FE1, FE2 and
FE3. The servers run on BE1, BE2 and BE3. Nodes TR1 and TR2 are routers
and have no application processes running on them. This diagram shows all
possible connections. The frontend connects to only one router at a time.
Example 2–1 shows the commands that have to be issued on each node to start
this configuration. Commands are issued first on node FE1, then on FE2, and on
FE3 for frontends followed by TR1 and TR2 for routers, and finally BE1, BE2,
and BE3 for backends.
Example 2–1 Local Configuration of each Node
% rtr
RTR> start rtr
RTR> create facility funds_transfer/frontend=FE1 -
_RTR> /router=(TR1, TR2)
% rtr
RTR> start rtr
RTR> create facility funds_transfer/frontend=(FE1, FE2, FE3) -
_RTR /router=TR1 -
_RTR> /backend=(BE1, BE2, BE3)
% rtr
RTR> start rtr
RTR> create facility funds_transfer/router=(TR1, TR2) -
_RTR> /backend=BE1
The commands shown in Example 2–1 could also be included in each node’s
startup script or put in a command procedure used to start the application.
Note that nodes only need to know about the nodes in the neighbouring layers
of the hierarchy, thus FE1 does not need to know about BE1. Superfluous node
names are ignored. This allows you to issue the same
CREATE FACILITY
command
on every node to simplify the maintenance of startup command procedures.
2–2 Starting and Setting Up RTR