| Oracle® Calendar Administrator's Guide Release 2 (9.0.4) Part Number B10892-02 |
|
|
View PDF |
| Oracle® Calendar Administrator's Guide Release 2 (9.0.4) Part Number B10892-02 |
|
|
View PDF |
A node network is a set of two or more connected nodes.
Once a connection between two or more nodes has been defined, all searches produce listings of configured users and resources from both local and remote nodes. This basic information is maintained on each computer in the node network. All calendaring data for each user and resource, however, resides only on that item's local node, eliminating space and consistency problems created by replicated databases. All exchanges of this information between nodes is done in real time, making local or remote location on a network completely transparent to the user.
When setting up a node, it is important to note that the node-ID cannot be changed once the node has been created. Furthermore, an existing local node will be deleted if a new local node is given a node-ID currently in use on the same computer. A warning prompt will be issued before this action is taken. Node-IDs are unique locally and across a node network. Two nodes with the same node-ID cannot be connected in a network.
This chapter details the following node network management tasks:
The network configuration is stored in one file ($ORACLE_HOME/ocal/misc/nodes.ini), and is managed using the uninode utility. The file must reside on only one of the host members of the node network, and commands can only be executed from this host. The uninode utility is used to connect or disconnect nodes in the node network, and to set the number of TCP/IP connections between the nodes, which are maintained by the Synchronous Network Connection (SNC) daemon/service.
The number of connections to establish between each pair of nodes in a node network is dependent in large part on the size and configuration of your installation. As a general guideline, smaller implementations are well served by a configuration in which a single node has two connections to each node in the network. All connections are one-way, so a network of 3 nodes would have a total of 12 connections:
A different set of guidelines applies to larger installations which fit within the following configuration parameters:
For any installation in this category, the general recommendation is to establish 4 connections each way between a local node and a node on a remote machine, and 3 connections each way between nodes on the same machine. Most installations can probably optimize this further.
The uninode utility is used for all node management tasks for the calendar server. For full information on use and syntax, see Appendix E, "Utilities" in the Oracle Calendar Reference Manual.
uninode -init to create and initialize a $ORACLE_HOME/ocal/misc/nodes.ini file. (In an Oracle Collaboration Suite installation, this file is created automatically.)
% uninode -init checking password for node 24, please wait... Enter SysOp password: connected to clio, node 24 extracted existing connection information created the "$ORACLE_HOME/ocal/misc/nodes.ini" file initialization succeeded
$ORACLE_HOME/ocal/misc/nodes.ini file contains the following header with a summary of uninode syntax and connection rules.
#Description File (nodes.ini) #------------------------------------------------------- #INCLUDE NODE: + H=Vancouver/N=10/ALIAS=Finance #EXCLUDE NODE: - H=Toronto/N=20 #NODE FOR MAIL: + H=Montreal/N=30/S=unison/G=unison/OU1=CS&T/OU2=R&D #ABSOLUTE RULE: all:2 #RELATIVE RULE: Vancouver->Montreal:+1
(In an Oracle Collaboration Suite installation, all is set to 3.)
NT:
Use a text editor to add the nodes to be connected and the rules governing the connections to the nodes.ini file. See "Syntax" and "Connections and Rules" later in this chapter for a discussion of the nodes.ini syntax, connections, and rules. Once you exit the text editor, uninode will prompt for confirmation of changes to be done to the network and automatically apply them.
UNIX:
Run uninode -edit and use a text editor to add the nodes and the rules governing their connections to the nodes.ini file. See "Syntax" and "Connections and Rules" later in this chapter for a discussion of the nodes.ini syntax, connections, and rules.
+ H=clio/N=24 + H=clio/N=25 included:2 ~ no errors detected 2 node(s) to ADD edit the temporary node file again? (y/n) n LAST CHANCE TO ABORT, process changes? (y/n) y checking if all nodes are up connected to clio, node 24 connected to clio, node 25 Processing node 24 connected to clio, node 24 connected to clio, node 25 added 24->25, TCP/IP connection Processing node 25 connected to clio, node 25 connected to clio, node 24 added 25->24, TCP/IP connection Do you want to update the directory of items (Actual = 0/Expected = 7)? (y/n) y placed a request in the CWS queue to get node 24 user directory 0 connection error(s), 0 processing error(s) Applying connection configuration: Successful
The $ORACLE_HOME/ocal/misc/nodes.ini file contains the list of the nodes and the list of rules that describe the network configuration. Any lines in the file which begin with the symbol "#" are considered comments and are ignored.
The minimal syntax for a node is:
+ H=<HOSTNAME>:<ENG_PORT>/N=<NODE-ID>
or
- H=<HOSTNAME>:<ENG_PORT>/N=<NODE-ID>
The <HOSTNAME> can be either a fully-qualified domain name, a machine name, or a numeric IP address. Do not, however, mix these in the same nodes.ini file. If you choose to use fully-qualified domain names, you must continue to use fully-qualified domain names throughout the file to avoid problems.
A node can either be included (+) in the network or excluded (-) from the network.
The following fields can be used to specify a node:
| Field | Description | Mandatory or optional |
|---|---|---|
|
H |
Host name:eng_port |
mandatory |
|
N |
Node-ID |
mandatory |
|
ALIAS |
Alias for Node-ID |
optional |
|
GR |
Group name |
optional |
If an alias is specified, it will be easier for users on all nodes of the network to identify where remote users are located, as this information will be displayed by the calendar client.
The group name is given by the administrator and is used to refer to a group of nodes. The interaction between the nodes of a specific group should be greater than with nodes of other groups. In most cases, a group name will represent a geographical area or a company subdivision.
Three predefined groups can be used:
all" refers to all included (+) and all excluded (-) nodesincluded" refers to all included (+) nodesexcluded" refers to all excluded (-) nodesTwo kinds of rules can be used. The first is used to specify the default number of connections between all nodes or between nodes within a group.
For example, say we have the following nodes in our nodes.ini file:
+H=mis-can1/N=1 +H=mis-usa1/N=2 +H=mis-eur1/N=3 +H=mis-eur2/N=4
To specify that two connections be established from each node to each of the other nodes, we use the predefined group "included" and add the following line.
included:2
The second kind of rule specifies the number of connections, from one node or group to another node or group.
N1->N2:X
N1 and N2 may either be host names, node-IDs, or group names. X may either be an absolute number of connections (0, 1, 2, 3...), or a relative number of connections (+1, -1, +2, ...). Rules are interpreted from the first to the last rule of the file. Consequently, the rules should be arranged from the most general to the most specific.
For example, to apply a more specific rule to this set of nodes, the group (GR) field can be useful in selecting these nodes.
+H=mis-can1/N=1/GR=Canada +H=mis-usa1/N=2/GR=USA +H=mis-eur1/N=3/GR=Europe +H=mis-eur2/N=4/GR=Europe included:2 Europe:+1
In the preceding example, we are able to add an additional connection (for a total of 3) to each of the European nodes relative to the absolute value defined on the preceding line.
Had we not wanted to use groups, we could also have said:
+H=mis-can1/N=1 +H=mis-usa1/N=2 +H=mis-eur1/N=3 +H=mis-eur2/N=4 included:2 mis-eur1 ->mis-eur2:3 mis-eur2 ->mis-eur1:3
Note that in this case we must specify the number of connections in each direction as SNC connections are unidirectional.
Replace the exclusion sign (-) of the host with the inclusion sign (+).
Replace the inclusion sign (+) of the host with the exclusion sign (-).
|
Warning: Deleting a node from the node network, even temporarily, will result in the loss of all remote records created on this node. |
To modify the number of connections between nodes, make the necessary changes to the rule entry. It is possible to add, delete or modify a rule entry.
Example: To increase the number of connections from Los Angeles to Cupertino by 2, add the following rule to the end of the file:
angeles->cupertino:+2
It is possible to tune the socket and/or transaction options of some or all of the connections to specific hosts and/or nodes. This may be useful in node networks with nodes distributed over multiple machines, where there are significant variations in performance among the connections. These variations may be due to differences in machine speeds, the speeds of the network links, the loads on the various machines, and/or the loads on the various calendar servers.
Tune the socket and/or transaction options by adding sections to the unison.ini file to define the relevant connections.
Each section heading has the syntax:
[<host>, unieng, <node>]
where
ALL to indicate all hosts in the node networkALL to indicate all included nodes in the node networkFor example, the section [murphy,unieng,all] contains parameters which tune all connections to all nodes on host murphy.
Each section contains one or more of the following parameters:
tr_block = 0 tr_recv_timeout = 60 tr_send_timeout = 0 so_rcvbuf = 0 so_sndbuf = 0 so_keepalive = FALSE
Each of these parameters overrides the value of the equivalent parameter in the [SNC] section of the unison.ini file. For example the tr_block parameter overrides the [SNC] snc_tr_block parameter. See the equivalent parameters in the [SNC] section in Appendix C, "Server Parameters" in the Oracle Calendar Reference Manual for an explanation of each of these.
You can set up a master node for your node network to control network management and ease the finding of user accounts on installations spanning multiple nodes and hosts. Use of a master node is optional.
unison.ini file on the calendar server host that contains the node you wish to configure.[CLUSTER] masternode parameter to the node-ID of the desired node.Entire nodes can be moved from one host to another. The following must be taken into account when moving a node:
Moving a node between a big-endian host and a little-endian host (or vice-versa) requires a database conversion. Contact Oracle support for more information about the conversion utilities unib2lendian (big-endian to little-endian), and unil2bendian (little-endian to big-endian) utilities.
| Big-endian | Little-endian (Intel processors) |
|---|---|
|
Solaris |
Linux |
|
HP-UX |
Windows |
|
IBM-AIX |
Compaq Tru64 |
Moving a node from an earlier version of the calendar server to a later version requires the use of the unidbconv database conversion utility. Note that it is not possible to move a node from a later version of the calendar server to an earlier version.
The procedure for moving a node between node networks differs from that for moving a node within a node network. This difference is in the utilities the procedure uses to update the node network information.
While most node network management is performed using uninode or the Calendar administrator, removing a node from a node network using either of these tools results in data loss. Namely, any calendar data created by a user in the node that is removed is deleted from all other nodes in the network. This is fine when moving a node between node networks. However, when you move a node within a node network, you want all nodes in the network to preserve all data related to the node. In this case you prevent the data loss by using the unidbfix utility to update the node network configuration. See "Performing the Move" later in this chapter for the exact procedure to follow in each case.
|
Note: If you are running a directory server, all nodes in a node network must point to the same directory server. |
If you are moving a node from a calendar server that uses an internal directory to one that uses an LDAP directory server (or vice versa), you should consult Oracle support for assistance.
The following procedures describe moving a node between hosts which:
The first procedure describes moving a node within a node network. The second procedure describes moving a node from one network to another. Although both procedures describe moving a single node, each can be adapted to moving several nodes.
unidbfix -c on the node you want to move to ensure that the database is not corrupted.$ORACLE_HOME/ocal/db/nodes/<Nx> directory, where <Nx> is the value of the name parameter that appears in the section of the unison.ini file configuring the node you want to move.$ORACLE_HOME/ocal/db/nodes/<Nx> directory now exists on the new host.
If a node with the <Nx> name already exists on the target server, you may choose to rename the node you are moving. Use the lowest unused letter-number combination. For example, if the last node on the target server is named N6, rename the new node N7.
$ORACLE_HOME/ocal/misc/unison.ini file on the old host and add it to the $ORACLE_HOME/ocal/misc/unison.ini file on the new host.
Remember that if you chose to rename the node in step 4, you must also rename the section configuring the node. Use the same letter-number combination you selected in step 4.
unison.dbd and vista.ctb files from the $ORACLE_HOME/ocal/db/nodes/Nempty/perm/ directory on the old host to the same directory on the new host.unidbfix -export -n all on each of the hosts in the node network. This creates a remotenode.ini file in each of the node database directories (i.e. in each $ORACLE_HOME/ocal/db/nodes/<node>/perm directory). This file contains information about all nodes remote to node <node>.remotenode.ini file of each node in the node network, replacing the old host name with the new host name.unidbfix -k on the newly-moved node to create the key files.unidbfix -import -n all on each host in the node network. This updates the node database for each node in the node network.$ORACLE_HOME/ocal/misc/nodes.ini file for the node network to reflect the host name change.ldapmodify tool, changing the old host name to the new host name on the moved node. This attribute exists for each SYSOP special user.$ORACLE_HOME/ocal/db/nodes/<Nx> directory on the old host.uninode -edit to edit the nodes.ini file and apply the change.unidbfix -c on the node you want to move to ensure that the database is not corrupted.$ORACLE_HOME/ocal/db/nodes/<Nx> directory where <Nx> is the name of the node you are moving.
$ORACLE_HOME/ocal/db/nodes/<Nx> directory now exists on the new host.$ORACLE_HOME/ocal/misc/unison.ini file on the old host and add it to the $ORACLE_HOME/ocal/misc/unison.ini file on the new host.ldapmodify tool, changing the old host name to the new host name on the moved node. This attribute exists for each SYSOP special user.$ORACLE_HOME/ocal/db/nodes/<Nx> directory on the machine which originally contained the node.uninode -edit to edit the nodes.ini file and apply the change.For nodes with and without LDAP connections to coexist in a network, the most recent version of the calendar server in the node network must manage that network. Furthermore, if there is more than one of the most recent version, and any use a directory server, one of those must manage the node network. Recall that all nodes in a node network must point at the same directory server.
The following procedure outlines the steps you must execute when you have a node network where all nodes currently connect to an external directory, and you want to introduce internal-directory nodes into the network. All calendar servers are assumed to be the most recent version.
To integrate the new internal-directory nodes into the node network, execute the following steps:
unison.ini parameter [DAS] enable=TRUE).[ENG] dir_internal_nodes in the unison.ini file, on all calendar servers in the node network which use a directory server, to include all non-LDAP nodes.
For example: with four nodes in your network, nodes 10000 and 10001 on the calendar server using a directory server, and nodes 10002 and 10003 on calendar servers using internal directories, the unison.ini file on the calendar server using a directory server would contain the following parameter:
[ENG] dir_internal_nodes = {10002, 10003}
unidssync to synchronize the LDAP nodes with the directory server.uninode to add the non-LDAP nodes to the node network.unidssync on a regular basis (at least once a week for most installations) to keep the LDAP nodes synchronized with the directory server.Slight differences in the UNIX and NT LDIF file formats must be understood in order to successfully transfer data from a NT to a UNIX server. Before importing NT-generated LDIF files to UNIX, ensure that:
If a master node is present in your node network, clients will query that master node for available server functionality such as wireless capabilities. If your master node server is set up with Oracle9iAS Wireless but the other nodes in your network are not, then clients of users whose accounts reside on those other nodes will behave as if wireless capabilities are enabled, but users will encounter errors trying to use those capabilities. Likewise, if your master node is not set up with Oracle9iAS Wireless but the other nodes in your network are, then all users' clients will hide or disable wireless capabilities (since the master node tells them no wireless capabilities are enabled on the server).
It is therefore recommended that you ensure that your master node has the same wireless capabilities as the other nodes in your network.
