|
|
|
|
|
CorporateTime Server |
Administrator's Guide |
| View in pdf format |
| Go to Reference Manual |
Deployment
This chapter outlines the deployment and installation of your calendar server. Prior planning is an integral part of a successful implementation in your organization. It is highly recommended that you read this chapter before installing the server to ensure an installation that is customized to your needs.
The following sections cover the information that you need to get your server up and running:
Deployment
To realize the optimal CorporateTime Server configuration for your organization, you must first evaluate who your users are, how they should be organized, and how the product will be installed and managed. Consider the following factors:
Number of users
The first step in planning a successful deployment or "roll-out" of CorporateTime Server is to determine the number of potential CorporateTime users in your organization. If growth is anticipated in your organization, factor this into your calculations. The final tally forms the basis for the value you supply for configured users in later calculations.
Acme Co. example
- Configured users: people with user accounts on a CorporateTime Server node.
- Logged-on users: users who are connected to a node but not actively making requests of the database. This figure is generally estimated to be anywhere from 33-50% of configured users. Try to forecast how your users will use the calendaring application. For example, if everyone starts work at the same time, you might anticipate a period of peak usage in the morning where up to 75% of all users will be logged on at once. Also, a number of users may choose to stay logged on all day, keeping the calendaring application open in the background to permit quick and frequent access.
- Active users: logged-on users who are making an access request to the database. To estimate the number of active users at any point in time, take 10-25% of the total number of configured users. As with logged-on users, base this number on your highest estimate of peak usage.
To illustrate the planning process for your CorporateTime Server implementation, we will use a fictitious company called Acme Co. The CorporateTime administrator at this company has chosen to make her estimates of logged-on and active users high to ensure that she has adequate resources and that the users can expect uniformly good performance.
Table 2.1 · Acme Company: user base Configured users 16,000 Logged-on users 8,000 (50% of configured users) Active users 4,000 (25% of configured users) Logical divisions of users
Once you have estimated your user base, the next step is to group these users according to location and function. Here it is important to identify not only geographic divisions, but also functional or other administrative divisions within your organization. You should use both geographic and administrative divisions to group your users into nodes.
Acme Co. example
In our Acme Co. example, the total user population of 16,000 is distributed in the following manner:
Grouping users to create nodes
With the logical divisions among your user base clearly delineated, you are now ready to group your users into nodes. Before making these decisions, however, a number of factors must be considered:
A node is a CorporateTime database containing agendas and information for users and resourcesAcme Co. example
- Node size
The maximum capacity of a CorporateTime node is 64,000 configured users; however, for performance reasons, this limit is not recommended except under exceptional circumstances of infrequent user connections. The recommended capacity per node and per server is heavily dependent on hardware and configuration. In an environment supporting any combination of desktop clients (Windows, Mac, Motif) and CorporateTime Outlook Connector, 10,000 users is a good working figure for maximum configured users. For environments consisting only of Web clients, use 20,000 as a base number. Use caution in determining an appropriate number for a mixed environment. For more information on tuning these numbers, contact a technical consultant at support@oracle.com.
See Appendix A, "Disk Space and Memory," and Appendix B, "Sizing Guidelines," for any additional node size restrictions.
- Network issues
Although server-to-server calendar communication requires low network bandwidth, in order to obtain acceptable performance for users accessing a remote server, a network bandwidth of 64 Kbps or higher is suggested. If this is not possible, it may be wise to consider installing a local server.
- Scheduling between nodes
More server resources are required when scheduling meetings between users on different nodes in a CorporateTime network. For this reason, it is good practice to group users who work together on one node and thereby minimize the number of meetings involving users from other nodes.
- User migration
Although it is possible to move individual users from node to node, the process can be lengthy and may alter or remove some information. Minimize the need to move individual users as a result of either reaching maximum node capacity, or the need to split a node according to logical divisions. For a more detailed discussion of the unimvuser utility, see Reference Appendix C, "Utilities."
- Administrative considerations
While the bulk of CorporateTime Server administration can be done remotely, there are tasks related to system maintenance that might require an on-site administrator. If you do not have personnel to manage back-up media and system problems at a branch office, then it is probably not a good idea to locate a server there.
The time required to administer your CorporateTime Server network is also affected by the necessary repetition of some tasks. Certain features, such as holidays, designates and members-only groups, are specific to each node. The tasks associated with these features, such as adding holidays or assigning designates, must be done separately on each node.
- Directory server
Each node in a CorporateTime node network that is linked to a directory server must point to the same directory server.
Our CorporateTime Server administrator has attempted to integrate all of the above variables with her user base calculations, arriving at the following configuration. In achieving this balance, she has considered a number of factors specific to her situation:
- The Los Angeles user base (12,000) is too large to group in a single node, thus she opted to create two nodes, following the administrative divisions, on two separate servers.
- The Chicago office is expected to steadily decrease as the sales force there is relocated to New York's office. Since the administrator wants to minimize the time required for administrative tasks, and not manage two nodes, she groups the New York and Chicago users in one node on a server located in New York. Having users in two different time zones on the same node will require a minor configuration change for the Chicago users to enable them to set their time zone from the client (see the [LIMITS] settimezone parameter in Reference Appendix B, "Server Parameters.")
- The final two nodes will be located on one server in Seattle. All Seattle users will be on one node, and all Vancouver users will be on the other node. Although there is no performance advantage in splitting the users between two nodes on a single server, a number of other factors have contributed to this decision. The on-site administrator is located in Seattle and the network bandwidth between the Seattle office and the Vancouver office is sufficient for the expected traffic. The Vancouver office is on a separate node, however, as it is expected to grow and eventually maintain its own support division. Thus, it is anticipated that the node will eventually migrate to a server in Vancouver.
The final configuration:
See Appendix B, "Sizing Guidelines," for information concerning memory and disk requirements for your installation.
Product administration
As a final task in this deployment exercise, determine who will be responsible for the different tasks which are part of setting up and maintaining a CorporateTime calendaring system. The major tasks are:
- system administration on the UNIX or NT server (including monitoring and backups)
- adding, modifying, and deleting users and resources
- resource administration (assigning designates)
- holiday administration
- front-line support
- client training
Pre-installation checklist
To ensure a quick deployment and minimize later tuning, a number of configuration issues should be considered before installation. Calendar server behaviour can be controlled by parameters set in the /users/unison/misc/unison.ini file. For more information on these parameters, see Reference Appendix B, "Server Parameters."
UNIX
- Kernel parameters
Operating system kernel parameters must be evaluated, and if necessary tuned, for each installation. Refer to Appendix C, "System Configuration," for information concerning the relevant parameters for each supported operating system, the procedure used to alter the current values, and the formulae used to derive correct settings for your installation.
- Client connections
The [LCK] lck_users parameter determines the number of available client connections to the calendar server. Set it high enough to accommodate the traffic and expected usage of each node, but be aware that setting this value too high will waste system resources.
- Mail notification
The [LIMITS] mail parameter enables or disables e-mail notification for all event or task creation. The default value enables this feature.
- Resource Relative DN
Installations using external LDAP directory servers can specify a location in the LDAP hierarchy in which all resources will be located by default. Consult the documentation on the [LDAP] resourcerelativedn parameter for details.
- Attachments
The [LIMITS] allowattachments parameter enables or disables the attachment of files to events or tasks created by clients. The default value disables this feature. If attachments are allowed, they may be limited in size using the [LIMITS] maxattachmentsize parameter.
- Group administration
The server offers four different group types: personal, members-only, public and administrative. All users have the right to create personal and members-only groups. The rights to create public and administrative groups must be assigned by the administrator, either individually or in batch mode using a default user profile. See Chapter 7, "Assigning administration rights," for a discussion of the differences between the group types and the methods used to change default administration rights.
- SYSOP (node) password
When you install the calendar server in internal directory mode, a SYSOP (node) password will not be assigned to the node created during the installation process. Sign in to the node to set a password before adding users. See Chapter 4, "Changing the SYSOP (node) password," for instructions on this process.
- ACE security framework
- The calendar server's Authentication, Compression and Encryption (ACE) framework is an extensible system ensuring the security and integrity of all information passing from server to server and between servers and clients. By default, the ACE framework is enabled; use the [ACE] frameworkenable parameter to disable it.
- Resource scheduling
Resources can either be set up on a first come first served basis where double-bookings are not permitted, or they may be set up to allow conflicts to occur. The default value for the [ENG] allowresourceconflict parameter prohibits double-bookings.
The following table presents a list of the major items to consider before installing the calendar server in internal directory mode:
Table 2.4 · Installation information checklist: internal directory Node-ID Recommended Node-ID ranges: 1-5: Evaluation 6-100: Test 101-9999: Permanent 10000-59999: Future use 60000+: Reserved (NOTE: this number must be unique across all connected nodes) Mandatory 1
Node Alias A descriptive word of up to 32 characters (no spaces) Optional N/A Time Zone See Reference Appendix D, "Time Zone Table." Mandatory N/A Number of Concurrent Users Any number between 15 and 2000(NT) or 5000(UNIX) Mandatory 100 Mail Notification Enabled (Yes) or Disabled (No) Mandatory Yes Mail Host Any host Mandatory if mail notification enabled local host The following table presents a list of the major items to consider before installing the calendar server to connect to an external LDAP directory.
Table 2.5 · Installation information checklist: external LDAP directory Node-ID Recommended Node-ID ranges: 1-5: Evaluation 6-100: Test 101-9999: Permanent 10000-59999: Future use 60000+: Reserved (NOTE: this number must be unique across all connected nodes) Mandatory 1
Node Alias A descriptive word of up to 32 characters (no spaces) Optional N/A Node (SYSOP) Password Up to 15 alphanumeric characters in length Mandatory N/A Time Zone See Reference Appendix D, "Time Zone Table." Mandatory N/A Number of Concurrent Users Any number between 15 and 2000(NT) or 5000(UNIX) Mandatory 100 Mail Notification Enabled (Yes) or Disabled (No) Mandatory Yes Mail Host Any host Mandatory if mail notification enabled local host Base URL for Directory Server A URL in this format: ldap://<LDAP host>:<LDAP port>/<Base DN> Mandatory ldap://<local host>:389/<no default for Base DN> Base DN The point in the directory hierarchy from which searches are performed Mandatory N/A SuperUser DN User with "unrestricted access". Must be a DN already in the directory server Mandatory none CorporateTime Administrators' Parent DN Any DN, offset from the base DN Optional If present, unison.ini value; otherwise N/A CorporateTime Administrators' Group DN A new group created under the base DN Mandatory If present, unison.ini value; otherwise "CorporateTime Server Admins" License keys and serial numbers
CorporateTime Server requires two distinct kinds of authorization strings to be provided by Oracle: license keys and serial numbers.
A license key is required in order to install and run your server. You will be prompted for this license by the installation utility. If you do not provide a license key at installation time, your server will use a demo license that will expire at a given point in time. The license key is written directly in the /users/unison/misc/unison.ini file on your calendar server host, in the value of the [LIC] license parameter. You may change your demo license to a permanent one at any time by simply stopping your server, changing the value of this parameter, and restarting your server.
Serial numbers determine how many users and event calendars each node of your server can accommodate (resources are unlimited). By default, your nodes will be created with a maximum capacity of 10 users. You can add serial numbers to your nodes using either the command-line utility unisnadd or the CorporateTime Server Administrator (Windows NT only).
To determine how many user licenses remain on any node, use the unistat utility with the -sn option. For full details on use and syntax, see Reference Appendix C, "Utilities."
To add new serial numbers to a node:
Admin GUICommand line
- Sign in to the node whose capacity you want to increase.
- From the Node menu, select Properties... and go to the Capacity tab. You will see a list of the serial numbers already applied to this node, as well as the total capacity and current number of configured users.
- To remove a serial number, select it in the list and click Delete. To add a serial number, click Add... and provide the serial number and a comment if desired in the Add Capacity dialog that opens.
- When you click OK in the Add Capacity dialog box, the new serial number should be included in the list.
Use the unisnadd utility. For full information on use and syntax, see Reference Appendix C, "Utilities."
Example
To add the serial number "3889hh983kl093ed" to node 234 of the current host:
- % unisnadd "3889hh983kl093ed" -c "comment on this sn" 234
|
|
|
|
|
| Copyright information | |||