| 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 |
This chapter examines the overall structure of the calendar server. An introduction to the concepts and terminology involved is followed by an examination of the function of the calendar server daemons/services, and an illustration of the basic internal operations and processes involved in client connections.
This section is a quick introduction to the concepts and terminology at the heart of the calendar server design. This information is intended as a preliminary to the architectural and structural information later in this chapter. More details on these subjects are presented in following chapters.
A host is the physical machine running an installation of the calendar server. It is possible to have more than one installation of the calendar server on the same host, except on Windows NT where only one installation of the server may be present on any one host. When more than one calendar server is installed on the same machine, the two are differentiates by the port number used to access them. This will be reflected by the <hostname:portnumber> combination used when accessing a server using a utility. For example:
uniping -host host1:5730
A node is a local database where the server stores information such as user records, meetings and events. Each node has a specific, unique identification number called the Node-ID. Multiple nodes may exist for the same calendar server. Nodes may also be connected into a node network, allowing users on separate servers to schedule meetings and events transparently with one another. When the calendar server is installed, a node is automatically configured.
A cluster is a node network in which one node is designated the "master node". The master node coordinates network management, finding user accounts on installations spanning multiple nodes and hosts. Use of a cluster type of network is optional.
When the Oracle Calendar Server is installed, by default it is integrated with the Oracle Internet Directory server (OiD) and other components of the Oracle Collaboration Suite. However, the Oracle Calendar Server can be deployed as a "standalone" application, storing all user information in a third party LDAP directory server. In either cases, the calendar server is said to be using an external directory.
The standalone installation also offers the possibility of installing the calendar server with no LDAP directory. In this case, the user information is stored in the calendar server's database and the calendar server is said to be using an internal directory.
The calendar server can contain up to six UNIX daemons/multi-threaded Windows NT services. The calendar server daemons/services are:
The Engine (uniengd) accepts and services calendar requests. All communication with the calendar database is handled by the engine. At startup, a series of uniengd daemons/services are started automatically for each node.
The first uniengd process created is the uniengd Controller. It then creates multiple uniengd Listeners. A listener listens for incoming client connections and either launches uniengd session processes or creates uniengd session threads for each client it accepts (depending on the OS of the system). One of the uniengd session belongs to the Synchronous Network Connection daemon (unisncd described later in this chapter).
Since many of the calendar requests can be received at the same time, the servicing engines rely on the Lock Manager to ensure orderly access to the database of the local node (see Oracle Calendar Lock Manager later in this chapter). Therefore the Lock Manager must be running in order for the Engine to function. The Engine must be running in order to operate the calendar server.
The Lock Manager (unilckd) queues and processes the many requests for access to the calendar server's database. The Lock Manager must be running in order to operate the calendar server. On Unix, it is possible to have more than one lock manager per calendar server when more than one node is configured for the same calendar server. By default, one lock manager exists per node. See server parameter [LCK] maxnodesperlistener in Appendix C, "Server Parameters" of the Oracle Calendar Reference Manual.
There is one Synchronous Network Connection daemon/service (unisncd) per server which services every node. It fulfills two roles in the server architecture. First, the unisncd is used to maintain open TCP/IP connections between nodes, and to grant those connections to clients that request access to another node. Each connection is unidirectional, from the current node to another node, but not vice versa. It is therefore important to ensure that node connections are set in both directions.
The Synchronous Network Connection daemon/service grants connections on a first in, first out basis. Requests that cannot be processed immediately are put in a queue. The number of connections between two nodes may be increased or decreased to minimize both the number of connections used and the traffic and connection time between two nodes. If a Synchronous Network Connection daemon/service loses a connection due to network problems, it will attempt to reconnect later.
In its second function, it is used in implementations with an external directory server, the unisncd acts as a broker, granting connections to the Directory Access Server (unidasd).
For technical information concerning the configuration of the Synchronous Network Connections daemon/service, including a list of parameters and their default values, see Appendix C, "Server Parameters" of the Oracle Calendar Reference Manual. Unless otherwise indicated, the Synchronous Network Connections daemon/service must be restarted in order for a configuration change to take effect.
The Directory Access Server (unidasd) is used to maintain open connections to an LDAP directory server. Connections to the Directory Access Server are granted by the Synchronous Network Connection (unisncd) daemon/service. The unidasd daemon/service is not used when there is no external directory. By default, more than one unidasd is started when the calendar server is started.
The number of unidasd connections to establish to the directory server is defined by the parameter numconnect in section [<YOURHOSTNAME>,unidas]. If this parameter is set too low, the server may not be able to handle all requests made for directory server operations, in which case end users will get errors of the type "Unable to contact directory server". For more details on the numconnect parameter, see Appendix C, "Server Parameters" of the Oracle Calendar Reference Manual.
The Corporate-Wide Services (unicwsd) daemon/service replicates data between nodes, provides e-mail notification through an SMTP mail server and wireless notification through Oracle's wireless services. It also processes server side reminders and synchronizes the calendar database with the directory server when necessary.
unicwsd communicates with other nodes using TCP/IP sockets and named pipe connections. These links provide fast communication. The TCP/IP sockets and named pipe connections are provided and managed by the Synchronous Network Connection daemon/service (unisncd).
By default, two unicwsd daemons/services are created when the calendar is started, one for the replication of calendar data between nodes and one for all the other tasks (mail, reminders, etc.).
For each of the following activities one CWS (Corporate-Wide Services) job can be enabled:
Replication: Node to node data replication
Messaging: Messaging requests for e-mail, wireless alerts, iMeeting, etc.
SSR: Server side reminders
Snooze: Handling snoozed requests
DirSync: Synchronizing with Oracle Internet Directory
EventSync: Updating synchronization data for events recently modified.
GALSync: Synchronizing the Global Access List.
A CWS task is a process that handles one or more jobs.
The server can be configured to support one or many separate processes per job using server parameter [CWS]prioritizedjobs and the maximum number of nodes a Corporate Wide Server task can service can be configured using [CWS] maxnodepertask. For more details on theses parameters, see Appendix C, "Server Parameters" of the Oracle Calendar Reference Manual.
For more information concerning the configuration of the Corporate-Wide Services daemon/service, including a list of all [CWS] parameters and their default values, see Appendix C, "Server Parameters" of the Oracle Calendar Reference Manual. Unless otherwise indicated, the Corporate-Wide Services must be re-started in order for a configuration change to take effect.
Whenever a client requires a service from the Corporate-Wide Services daemon, a request is put in a local queue and the appropriate unicwsd will service it depending on the type of the request. One of the unicwsd daemon/service processes the requests by reading them from the queue.
When a remote node is temporarily shut down, replication requests destined for that node are accumulated in the queue and tagged as on hold until the node becomes available again. Similarly, if for any reason, mail cannot be sent, mail notification requests will accumulate in the queue. The utility unireqdump can be used to output the set of requests currently in the queue of the Corporate-Wide Services daemon/service. For more information on the utility unireqdump, see Appendix E, "Utilities" of the Oracle Calendar Reference Manual.
The Calendar Server Manager or CSM (unicsmd) provides the capability for remote administration of the calendar server. The following administrative operations will use the services provided by the CSM:
In order to start a server remotely, the server must be in "stand-by" mode. In this mode, all daemons/services are stopped except for unicsmd which is left up and running and waiting for a remote calendar request. If a server is stopped completely (all daemons/services are stopped including unicsmd), it will not be possible to restart it remotely.
At installation, the CSM is configured with the parameters in the [CSM] section of the $ORACLE_HOME/ocal/misc/unison.ini file. The port parameter specifies the TCP/IP port on which the unicsmd daemon/service listens. This port needs to be opened (as is the port for uniengd) on any firewall for remote management of the server to be possible. Remote management of the server can be disabled by setting the enable parameter to FALSE.
In a standalone installation of the calendar server, the password parameter must be specified in the [CSM] section of the unison.ini file. This will be the password to access the local calendar server via unicsmd from a remote location. In configurations where the complete Collaboration Suite has been installed, the SYSOP password is used. The ACE (Authentication, Compression and Encryption) framework is not used when authenticating remotely using the CSM. For more information on ACE, see Appendix C, "Security".
|
Note: There is only one password for remote access. Two administrators who remotely manage the same server will use the same password, and there will be no way of determining who did what. |
The calendar utilities that use the services of the CSM are unistart, unistop, unistatus and the Calendar Administrator. When accessing a remote server, the local utility is invoked with the host name and port number of the remote server's CSM which must be specified using the -csmhost option. The CSM password (for standalone installations) or SYSOP password of the remote server must be supplied; for example:
% unistart -n 120 -csmhost hercules:7688 Passwd:
The local utility communicates with the remote CSM which will invoke the remote version of the utility. Error codes and output produced by the remote utility will be passed back and displayed by the local utility. However, any log output will only be written to the log files on the remote host. You will need to sign-in to the remote host directly to access the log files. For more information on unistart, unistop, and unistatus, see Appendix E, "Utilities" of the Oracle Calendar Reference Manual.
The Calendar Administrator can also be used to manage a calendar server remotely. As with the utilities, you will be required to enter the remote host name, CSM port and password.
Note that the CSM is an optional part of the calender server. Whether unicsmd is up or down, it has no impact on the local calendar operations. In case of CSM failure, normal calendaring operations will not be affected. Only the ability to manage the server remotely will be affected.
The remote administration is cross-platform: a calendar server on a Windows NT system can be started remotely from a calendar server on a Solaris machine and vice-versa.
When the Collaboration Suite is installed, the default configuration uses the Oracle Internet Directory to store user attributes. All nodes in a node network must use the same directory server. Figure 2-1 shows the Oracle Calendar internal architecture.
Text description of the illustration calarch.gif
For each client it accepts, the uniengd listener either forks a uniengd session process or creates a uniengd session thread. All subsequent requests from a client are sent to the client's dedicated uniengd session. This is referred to as a "persistent connection".
In the course of a user session, calendar and user information may be viewed, created, modified, or deleted. These operations involve either reads from, or writes to, node databases. The client's uniengd session handles reads and writes on the local node (the node containing the user) differently from reads and writes on remote nodes.
To perform reads or writes on the local node, the client's uniengd session requests access to the node database ($ORACLE_HOME/ocal/db/<node name>) from the unilckd. When the unilckd grants access, the uniengd session performs the read or write operation. It then relinquishes access to the node database, and if necessary, returns data to the client.
To read information from a remote node, the client's uniengd session requests a connection to the remote node from the unisncd. When the unisncd hands it a connection to that node, the client's uniengd session sends the read request to the uniengd server at the other end of the connection (see "Connections to Nodes" later in this chapter). The remote uniengd server then requests access to its local node database from its unilckd. When the unilckd grants access, the uniengd server retrieves the information, relinquishes access to the node database, and sends the information to the requesting uniengd session. The requesting uniengd session receives the information, returns the connection to the unisncd, and hands the information to the client.
Writes to a remote node arise when the user adds, modifies, or deletes calendar and/or user information. In this case, the uniengd session places a request in the queue of the local node (see "Node Request Queue" later in this chapter for a discussion of the node queue). Another uniengd session associated with this local node services these requests in the same manner as reads on a remote node.
unisncd establishes persistent connections to other nodes on startup, using information in the $ORACLE_HOME/ocal/misc/nodes.ini file to determine the number of connections to establish to each node. It establishes a connection by sending a request to the uniengd daemon/service (the uniengd daemon/service on the local host for nodes on the local machine, and the uniengd daemons/services on remote hosts for nodes on remote hosts). That uniengd daemon/service creates a uniengd session process or thread to handle requests to the specified node. A uniengd session sits on the end of each connection to a remote node. Each of these sessions obtains access to their node database from unilckd.
Each node has a request queue associated with it. This request queue is maintained within the node database and used by all uniengd sessions associated with the node. These request queues contain requests for alerts and e-mail notification, and requests for replication of data (resulting from creation, modification, and/or deletion of calendar information).
unicwsd manages the request queue of each node on the local host. On startup, unicwsd sends a request to the uniengd daemon/service for a uniengd session for each node on the local machine. The uniengd daemon/service then creates one uniengd session process or thread per node to service each node's request queue. The diagram shows one of these uniengd sessions.
unicwsd examines each request in the request queue and determines how to handle it. If the request is for a mail notification, it hands the mail to the mail server. Similarly, it passes requests for wireless reminders and notifications to the Oracle9iAS Wireless server. If the request is for a write to a remote node, it hands the request to the uniengd session servicing the request queue of the node. unicwsd also deletes redundant requests in order to optimize performance.
On startup, unisncd reads the numconnect parameter from the [YOURHOSTNAME, unidas] section of the $ORACLE_HOME/ocal/misc/unison.ini file to determine the number of connections to establish to the LDAP directory server. It then sends a request to the unidasd daemon/service. The unidasd daemon/service spawns a unidasd server for each of the requested connections. When a uniengd session requires directory server access, it requests a connection to a unidasd server from unisncd. unisncd passes a connection to the requesting uniengd session, which retrieves the necessary information from unidasd and subsequently returns the connection to unisncd.
