Global System Services Corporation (GSS) - The leading provider of email and messaging, directory services, and groupware consulting and professional services

Capacity planning and system design determine several important characteristics of a cc:Mail system. Capacity issues affect the performance, reliability and maintanability of the system. System design affects performance, maintainability and the amount of administrative overhead for maintenance. These topics are fairly advanced but since an ounce of prevention is worth a pound of cure, I wanted to cover them before jumping into the how-to aspects of setting up a cc:Mail system.

For the purposes of this chapter, an understanding of OSI model networks and cc:Mail system architecture is assumed. If you are new to cc:Mail, you may want to read the capacity planning section and return to this chapter again later. Issues internal to the cc:Mail system, such as the numbers of post offices and cc:Mail Routers, are discussed in the system design section of this chapter. Server disk space requirements are discussed in the capacity planning section. Implementation planning is covered in Appendix B.

More than client/server systems, the performance and reliability of cc:Mail systems depends on the stability and performance of the network environment. As a result, some capacity planning issues for cc:Mail are really network design issues while others are cc:Mail-specific. Most of the literature pertaining to cc:Mail does not discuss network design issues because in stable network environments with low and moderate loads, cc:Mail systems tend to be very reliable.

The network design aspects of capacity planning involve the anticipated load on file servers and networks as well as file server storage requirements. Ideally, networks and file servers with capacities appropriate for immediate and near-term loads should be in place before a new cc:Mail system is rolled out. However, anticipating the load on networks and file servers produced by a cc:Mail system is extremely difficult. In fact, it is not possible to accurately predict the load that a cc:Mail system will produce because there are too many variables and not all of them can be known in advance. Nevertheless, because network design issues are critical to cc:Mail, I have listed some of the key issues below. The issues can be broken down into local area network issues and wide area network issues.

Key LAN capacity planning issues include:

Key WAN capacity planning issues include:

Think of these issues as things you should consider before implementing a cc:Mail system. Although the load on networks and file servers that a cc:Mail system will produce cannot be accurately predicted, capacity planning for cc:Mail always begins with a knowledge of current utilizations and capacities.

In an ideal world, you would be able to determine the load on networks and file servers that a cc:Mail system will produce. Although not all of the variables can be known before the system is in full production, some of them typically are known ahead of time.

Commonly known LAN variables include:

For some network applications these factors would be adequate to predict network load. For example, to implement software to make customer records available to customer service personnel when customers called, capacity issues might be broken down as follows:

A test system could be used to estimate the amount of network bandwidth that the application would consume. Network analysis tools such as a Network General Sniffer, HP OpenView or CoroNet Super Monitor could be used to determine the total amount of data transmitted over the network for each one-record transaction and the amount of time required for each transaction. Combined with the call volume, an estimate of the total amount of data transmitted over the network during each hour of the business day could be calculated. The result could be compared to the known network capacity and current bandwidth utilization.

In other words, it wouldn’t difficult to tell with reasonable accuracy whether implementing such as system would overload the network during peak network utilization and call volume hours. Redesigning or upgrading the network could become a prerequisite for the project. Unfortunately, not everything is as neat and tidy as predictable call volume and customer records of known sizes.

Although no one wants to implement a network application on a production network without knowing what will happen, e-mail is something that the users themselves have a certain amount of control over. Users control the e-mail system through the way that they use it. If you have a site with 500 users, it makes a great deal of difference whether each user sends and receives an average of 3 to 5 messages a day or 25 to 30 messages. It also matters whether the messages are addressed to users at the same post office or other post offices. It matters much more whether the messages are simple text or contain files, and whether the files are documents, fax images or QuickTime movies.

Variables that are not known before a cc:Mail system is implemented include:

New cc:Mail administrators usually ask what the average values for these variables are. Unfortunately, averages are not known. Average values cannot be known without conducting a rather sophisticated study involving sites of various sizes in different industries with different system designs. What is much more important, however, is that any averages that could be known would not be very meaningful for a new installation.

A group of 200 users on one post office at a law firm might e-mail 500 or more 100K to 250K documents every day. If the users never deleted any messages, which is likely in a legal environment, the post office could grow as much 90MB per day. If, on the other hand, they sent 1,000 1K text messages per day and half were deleted after being read on the same day, the post offices might grow by less than 500K per day -- less if additional messages older than one day were deleted each day.

In practice, cc:Mail administrators deal with the network design aspects of cc:Mail in one of three ways:

1. Make an educated guess
2. Base expectations on a similar site in the same organization
3. Over-engineer

Other than server storage and workstation requirements, most smaller cc:Mail systems are implemented without a detailed review of capacity issues. Most of the time there are no negative consequences. A properly engineered 16Mbps Token Ring network with an average 20% utilization during peak hours is probably a hospitable environment for a cc:Mail system. A 66MHz 486 NetWare 3.11 file server with 32MB of RAM less than 100 DOS and Windows users can almost certainly host a 100-user cc:Mail post office as well. In low utilization environments, making educated guesses about capacity issues is fairly safe.

Internal comparisons, while perhaps better than averages, may not be valid for the same reasons that averages are not meaningful. Users in an advertising department may e-mail large graphics files to one another while accountants may e-mail smaller spreadsheet files. A valid internal comparison requires finding a similar group of users. However, even when this is possible, there is no guarantee that the new user group will use e-mail in the same way as the reference group.

I recommend an over-engineering design philosophy. Over-engineering means deliberately implementing systems the capacities of which exceed any reasonably foreseeable near-term load.

On its face, over-engineering faces the same problems as capacity planning in general because maximum loads are unknown. Nevertheless, theoretical maximums can be determined for worst-case scenarios. For example, if 33% of 350 users on one post office each sent messages averaging 25K simultaneously, this would mean approximately 158 workstations pouring about 4MB of data into the same file server. To make this work, however, you still have to guess how users will use the system. If, in the same example, 5% of users sent messages with 1MB file attachments simultaneously, this would mean approximately 18 workstations pouring about 18MB of data onto the network.

The short answer is that over-engineering also involves guesswork. Using the maximum supported file server volume size for cc:Mail post offices, for example, means guessing that post offices are very unlikely to exceed this size.

Over-engineering is the best insurance money can buy when it comes to mission-critical applications. When a mission critical system fails, there is a loss of productivity. Employees get less work done in the same amount of time, although they are paid the same. If a critical system fails and 200 employees lose 10 minutes of work each, approximately 33 person hours of labor are instantly destroyed. If the average employee earns $25.00 per hour, $825.00 are lost the second the failure occurs. Losses do not stop there. Employees are not paid to wait for information systems to come back on line so they can work.

In most organizations, networks and e-mail are mission critical systems. If a post office goes down because a server was configured with 32MB of RAM instead of 128MB; or because one less $3,000.00 network router was used in the network design, the small savings on paper can rapidly translate into many times as much in hidden losses. From this perspective, over-engineering for cc:Mail system is a financially sound strategy.

File server volume sizes, the number of post offices and the number of users per post office, are closely related. The value of each of these variables depends both on the other two and on how much message data each user will have. The amount of message data each user will have depends on other variables such as the number of messages, the sizes of messages, and the length of time that messages are retained. The amount of server disk space required for a given cc:Mail post office depends on several variables, including:

For versions prior to Release 6, Lotus recommends 100 users per post office and 10MB of server disk space per user. The absolutely arbitrary 10MB per user number has is a good rule of thumb. For versions prior to Release 6, the maximum server volume size supported by the cc:Mail maintenance utilities was 2GB. For Release 6 and later, the maximum supported volume size doubled from 2GB to 4GB.

If messages exchanged between other post offices are routed through a post office, server disk space requirements will be increased. For versions prior to Release 6, running the maintenance utilities can significantly reduce post office size. In versions prior to Release 6, free spaces in the post office caused by message deletions were not reused efficiently.

Unless the cc:Mail system has less than 100 users, I recommend always using the maximum supported volume size and for versions prior to Release 6, you should reserve at least one additional 2GB volume for maintenance purposes.

Although there is no mechanism within cc:Mail to limit the amount of disk space allocated to each user, as an administrator, you can push back user control by establishing policies regarding what can be sent through the cc:Mail system and how long messages can be retained. Nonetheless, you cannot control how many messages users will send and receive, when they will send them, and, beyond a point, how large messages can be.Here are some of things you can do to keep server disk space utilization under control:

Within a cc:Mail system, capacity planning means more than determining an adequate number of cc:Mail Routers and e-mail gateways. Ideally, the system would be designed to support specific service levels.

Installation requirements for cc:Mail Routers and e-mail gateways as well as for user workstations are straightforward. The numbers of users, post offices, cc:Mail Routers and e-mail gateways that will be part of the cc:Mail system are part of the system design. Performance, however, is difficult to predict. If you wanted to determine the number of cc:Mail Routers that you would need based on an arbitrary end-to-end delivery time for messages, you would have to know how many messages users will send, when they will send them, and what sizes the messages will be.

Grappling with cc:Mail system performance, it is possible to over-engineer the cc:Mail system itself but I don’t generally recommend this. If there is a need for high-speed message delivery throughout the cc:Mail system, a special message routing system can be put in place only for urgent messages.

Performance can be defined in terms of user mail application response times at the front-end and end-to-end message delivery times at the back-end. Quick response at the desktop depends on several factors. I have listed the main factors below, ranked according to overall impact. The factors that are most significant, however, are different at different times. A slow server, for example, may be the most significant factor overall, but running an on-line reclaim (Release 6 and later) will degrade performance temporarily but to a greater extent.

User mail application response times depend on these factors:

The performance of cc:Mail Routers and e-mail gateways is influenced by all of the factors that affect user mail applications. Within the cc:Mail system, end-to-end delivery times generally depend on these factors:

For cc:Mail Routers and e-mail gateways use 33MHz or faster 80386-based IBM or compatible machines. If you are running cc:Mail Multisession Router under OS/2, you’ll need at least 16MB of RAM or more. However, DOS-based back-end components, such as cc:Mail Router for DOS, use DOS conventional memory (the first 640K within the first 1MB or RAM)

TIP: For DOS machines running e-mail gateways that use a local hard drive for transient data, use 4MB of RAM and run SMARTDRV.EXE for local disk caching. If you need to load multiple

No one who is technical is going to want to just maintain post offices. After a while of maintenance including the normal adding/deleting, a technical person will become bored with just cc:Mail administration.

Generally as your users become more familiar with cc:Mail, they require less help. If they are your more sophisticated users and want to take advantage of all the features and have numerous options (aliases, bankshot routing, Internet addressing, and anything else they can think of), then it can be a full time job even with 400 users. So it depends on how demanding your users are regardless of just size.

I would always recommend having at least a part time back-up. Usually a technical person who acts as a network administrator can do this. Assuming that this person will only be called on occasionally and not for everything mail related.

Making improvements to the mail system takes time, and maintenance takes more time. When DB8 comes out, it will take less time.

We are a very large site. We have about 5 persons just for cc:Mail related work. It does involve some network administrator work, but only to support the mail. We are constantly making changes both to the directory and to the system to improve it. We have very demanding users that want to do everything. The through-put is very high as well. They want the messages to get around the country fast. This takes up a lot of time.

We have over 1,500 users on 6 post offices and we leave all the cc:Mail administrator to one person. And not only that, it isn't his only job. The job has traded hands a bunch of times, but e-mail administration is pretty easy once all the batch files are written to do the maintenance.

Up until now, we have really had two cc:Mail administrators - one was the network supervisor who had responsibility for the entire network including installation/setting up of cc:Mail post offices, router, gateway - the more, what I consider, technical side of the administration. The other responsibilities (my job) include user support (425 users, 6 post offices). I add/change/remove users, unlock accounts, train, and install at the user's workstation (including mobile setups) and do all the support. I'm the user contact person and only call in the network person when needed. Our network supervisor left and we're kind of in limbo now, although we do have two other network people that have been able to take over and assist me as needed. Fortunately, we haven't had the need to setup any new post offices or anything.

My question is how do other cc:Mail sites handle their administration - do you have one person to do it all? Or do you have a help desk function or what? Any information would be helpful to me.

You can save yourself some headache later if you take a minute to create a scaleable post office naming convention. Post offices are usually named in straightforward ways easily understood by users and administrators. A telecommunications company called Two Cans and a String, Inc., for example, might name the first post office TCSI, TCSI-01, or simply TwoCans. Other post offices might be named according to department or location, such as TCSI-SALES or TCSI-BOSTON.

A larger organization may have one or more post offices used for message routing or communication with external e-mail systems. These ‘hub’ post offices usually indicate the company name and geographic location.

Although a post office name could contain characters or strings of characters such as ?, $, "", $_$P$G, or %1, these characters cannot easily be used in OS/2 command files, DOS batch files or UNIX shell scripts. Some of these characters cannot be used on a command line because they have special meanings for the command interpreter or shell (COMMAND.COM for OS/2 and DOS and usually /bin/sh or /bin/csh in UNIX). Characters such as @, }. (, or [ can be used but these characters can be problematic when exchanging mail with other types of e-mail systems that assign special meanings to these characters. As a rule of thumb, only numbers and letters should be used in post office names. The dash (-), underscore (_), and tilde (~) characters, however, are often used. Spaces on the other hand are almost never used and I do not recommend using them.

Ideally, post office naming conventions should be simple and understandable. On the other hand, if every organization used names like ACCOUNTING and E-MAIL it would be very difficult to connect cc:Mail systems across organizations. Post office names should be as unique as possible so long as they remain meaningful. From an administrative point of view consistency and meaningfulness are paramount while for users names like SALES and MANUFACTURING are preferable. Use your judgment.

I recommend entering names last name first as in "Smith, John." Enter the last name, a comma, then a space and then the first name and press the Enter key. Other naming conventions such as first-name-last-name ("John Smith"), initials ("JS") or first initial and the first seven characters of the last name ( "jsmith") are allowed. As with post office names, you should avoid using characters other than alphanumeric characters.

The cc:Mail Mobile products can communicate with the cc:Mail Router using telephone modems or LAN protocols such as TCP/IP or IPX. A Router-to-Mobile connection, however, never involves a user mail application accessing the post office files over a LAN.

Most cc:Mail users access a post office over a LAN, as opposed to using cc:Mail Mobile. The cc:Mail Mobile product can use a modem or a LAN protocols to communicate with a cc:Mail Router but the regular, LAN-based user mail applications, like cc:Mail for Windows cannot. The LAN-based user mail applications do not directly use LAN protocols to access the post office files. File sharing services are provided by other software that does not directly interface with the user mail applications. Although, all network operating systems use LAN protocols, it would not be correct to say that cc:Mail uses a particular protocol.

Although cc:Mail Router and Mobile can interface directly with LAN protocols like Novell’s SPX, it’s important to understand that the LAN-based user mail applications do not. This can be confusing because the cc:Mail Mobile products can function both in file sharing mode and in Mobile mode. When cc:Mail Mobile is run in file sharing mode it uses the same mechanisms used by user mail applications such as cc:Mail for OS/2 Workplace Shell.

The ability of the cc:Mail Mobile products to run in both a file sharing mode and in a Mobile mode sometimes results in a misunderstanding of how the cc:Mail system works. As a result, administrators sometimes mistake the protocols used by their network operating systems as the mechanism by which the user mail applications access the post office files. For example, when file sharing services are provided by the Microsoft Lan Manager network operating system, you might think that that "cc:Mail uses the NetBEUI LAN protocol." While this is true in a sense, the user mail applications function independently of underlying network protocols. They rely on file sharing services provided by other software.

Remember that the cc:Mail post office is not a server or server processes in a client/server system but merely a set of shared files. The user mail applications read and write to the post office files using the same higher-level mechanisms regardless of what network operating system software and underlying protocols allow the post office files to be shared.

The comment field is used by the LMX (formerly SoftSwitch Central) e-mail gateway and by Lotus Organizer. Organizer right justifies user information leaving the left porting of the comment field free for normal use. The LMX gateway places a mainframe DGN.DEN address in the comment field. The DGN.DEN address is left justified.

A list of user names from a mainframe host or other system can be used as the basis for constructing a cc:Mail Import file to populate your cc:Mail directory. The cc:Mail Import file format is a simple ASCII text file format defined in the cc:Mail Import/Export manual. A list of user names, one per line, can be converted into a cc:Mail Import file in a variety of ways, such as using a UNIX shell script or a small program.

If you are using a version of cc:Mail prior to Release 6 and you are using Novell NetWare or Banyan VINES you can populate your cc:Mail directory using the cc:Mail Directory Services program (refer to the documentation that came with your cc:Mail products for more information).

In practice, many implementations had more users per post office with no negative consequences. What’s good about the 100 user number is that smaller post offices take less time to maintain and fewer users are affected if the post office is shut down. However, in larger systems, the number of 100-user post offices can become unmanageable.

For versions prior to Release 6, the maximum server volume size supported by the cc:Mail maintenance utilities was 2GB. This means that with a server disk space allocation of 10MB per user, there could be approximately 210 users per post office. Since messages temporarily accumulate in queues for other post offices and because free spaces were not 100% reusable between maintenance cycles, 200 users per post office is a good rule of thumb.

For Release 6, the maximum volume size doubled from 2GB to 4GB. This means that, without multiple message stores per post office, a reasonable maximum number of users per post office is still 200.

DISSEMINATION, DISTRIBUTION OR COPY OF THIS INFORMATION IS STRICTLY PROHIBITED. NO PART OF THE INFORMATION CONTAINED HEREIN MAY BE REPRODUCED IN ANY FORM BY ANY ELECTRONIC OR MECHANICAL MEANS, INCLUDING PHOTOCOPYING, RECORDING, OR INFORMATION STORAGE AND RETRIEVAL, WITHOUT THE WRITTEN PERMISSION OF GLOBAL SYSTEM SERVICES CORPORATION.