NETWORK DESIGN MANUAL Designing a Client/Server Electronic Messaging System by Barry Gerber 7. Design Servers and Client Connections to Them There is quite a bit to do here. You need to make a number of decisions about your e-messaging servers. Then, you have to make sure you have adequate bandwidth on your local networks to keep your e-messaging system happy. If not, you have to decide how to get it. Finally, you have to think about remote users and how you will connect them to your e-messaging system. Design E-Messaging Servers You need to think about several issues in designing your e-messaging servers. These include: How to manage server load How to manage user demands for storage How to protect the system from outages, crashes and data losses Managing Server Load The intricacies of e-messaging server load handling and tuning could occupy a whole book. You have to experiment here, using the expected user demands you came up within step one. If your e-messaging system comes with some sort of load simulation software, as does Microsoft Exchange Server, you can use it. If not, you will have to enlist a corps of human users to help you figure out how many users you can expect to put on a server. You can also ask the vendor of your e-messaging system for references. Here are some general thoughts and guidelines regarding e-messaging server load handling. If you think you have too little machine for your needs, start by increasing memory. Then think about server hard disk. Try distributing files differently. For example, if your e-messaging system allows it, try putting public forums or folders on a different disk drive, RAID array or even server. This can significantly improve performance. If all of this still isn't enough, add processors or look at the more powerful processors your e-messaging system supports. If vertical scaling doesn't solve your problem, consider going horizontal and splitting users across multiple e-messaging servers. Managing Storage You will need to start thinking now about how you are going to manage user storage on your e-messaging servers. Storage management gives you more control over how much of what is stored on server disks and helps you remain within your server disk budget. You will want to answer several disk management questions here including: If your e-messaging system lets users store their messages locally, do you want to take advantage of this feature for any or all users? If your e-messaging system lets you limit the amount of storage a user can have on the server, do you want to impose such limits for those who store their messages on the server? If your e-messaging system lets you impose limits on the storage used by public forums or folders, do you want to do so? You can base answers to m ost of these questions on the results of your user-needs assessment, though you are bound to make adjustments as you pass through iterations of the design process. Protecting Servers There are two steps you absolutely must take to protect your servers. First, you should install an uninterruptable power supply (UPS) on each. Second, you should establish a regular backup process for each server and follow it to the letter. UPSes You need to plan for UPSes on your servers. You should consider a UPS an integral part of server hardware, not an add-on. UPSes are cheap, given the piece of mind they can bring. You really don't want your e-messaging servers crashing because of power losses. Get enough UPS for the power needs of each server and get a UPS that comes with software to gracefully shutdown your servers if power stays off for an extended period. Backup When you know what your e-messaging servers and networks will look like, you can begin thinking about backing up your servers. If available, use backup software that is specially designed your e-messaging system. Such software should be able to backup your e-messaging system in its entirety, including open databases. You can backup your e-messaging servers either locally or over the network, depending on the capabilities of the backup software and the amount of data to be backed up. As a rule of thumb, for e-messaging servers with large amounts of disk (5 or more GB) and slow network links to potential backup servers (less than 100 Mbps), local backup on and from each e-messaging server makes the most sense. You will have to spend some money on a backup device and backup software for the server, but you will get that back in available bandwidth and faster backups. Available bandwidth means other network dependent tasks run faster. Faster backups mean shorter periods of that awful feeling you have when important data is not yet on tape. Whether you back up over the network or locally, don't skimp on backup hardware. You are going to add hard disk storage to your e-messaging servers, not take it away. Go for high capacity 4 or 8mm systems. Think about tape autoloaders that give one or more tape drives automatic access to anything from a few to hundreds of tapes. If users store messages on their workstations, be sure to decide who will be responsible for backing them up: the e-messaging staff, other MIS staff or the users themselves. If you want to centralize backup of user workstations, you will find that the technology is readily available for most operating systems. Networking E-Messaging Users Once you have completed the server design process, you have to think about how you will connect users to your e-messaging servers. It's usually a no brainer for local connects, though you will want to be sure you have enough bandwidth to move all of the kinds of messages your e-messaging system will make available to your users. For example, if users are likely to embed large graphics or OLE 2 applications in messages, you don't want to link them to their e-messaging servers using 4-MB Token-Ring or 2.5-MB ARCnet or even very busy Ethernet nets. If you are concerned about LAN bandwidth, you can do a couple of things. First, you can get rid of those slower networks. Dump 4-MB Token-Ring and ARCnet networks. Second, you can segment your LANs to reduce the number of users on any segment. In this situation, you might even put multiple network adapters in your e-messaging servers, one for each segment or group of segments. Yes, either of these options will cost your organization some dollars, but it's likely to be dollars well spent. Networks are the same as user workstations: Slow technologies are less likely to be used and the benefits of the applications you are trying to run on top of them are lost. Don't forget remote e-messaging users. Many users need to keep in touch when they are away from th e office, whether at home or on the road. Remote control software is passé. A good e-messaging system will allow remote users to connect to your network as though they were hardwired to it. Client e-messaging software should let remote users connect only to send and receive messages, letting them work offline the rest of the time. Another increasingly popular connect mode for remote users involves use of the Internet. E-messaging servers or intermediary systems have live links to the Internet and run standard Internet applications such as Telnet, POP or IMAP servers. Users access their messages running Telnet, POP or IMAP clients. With sophisticated e-messaging clients like Microsoft's Exchange client for Windows95 now supporting POP mail and UU or MIME decoding, Internet mail access need not be limited to simple text messages. Most e-messaging systems do not yet support remote access over the Internet. Such access is most likely to be found in Unix-based SMTP systems. Third-party enabling products are becoming available for some e-messaging systems. Whatever remote access capabilities you provide your users, be sure to plan for enough remote links. Err on the side of too many links. Users are quick to realize the advantages of e-messaging and soon start checking messages not just while on the road, but also while at home. 8. Decide Where E-messaging Servers Will Be Located Generally, the best rule here is to keep servers close to their users. Modern e-messaging systems allow for and even encourage the development of fancy and often high megabyte content. You don't want your users accessing massive messages over slower WANs or even highly segmented, heavily routed LANs. The best rule of thumb here is that it should take no longer to access a message of a given size than it takes to access any other executable or data on the local net. Beyond localization of servers, the next thing to consider is intelligent replication of ke y public forums or folders across servers. Cross-server replication lets you localize important information on a server-to-server basis. It only allows one transfer of information across local or wide area networks, usually at times you select. It is the best compromise between distributed e-messaging and the need for common information across an organization. 9. Decide How You Will Link E-messaging Servers Inside Your Organization When linking your e-messaging servers, you will have to choose from a set of e-messaging product-specific options and a set of networking options. The first set of options provides the link between your e-messaging server software and the second set of options, the physical network. Selecting E-messaging Product-Specific Server-To-Server Connectivity Options Some e-messaging products let you select from a range of server-to-server connectivity options. For example, Microsoft's Exchange Server lets you link servers both directly (through continuous connections) and indirectly (by sending all server-to-server communications as messages through other messaging systems). Within either of these options, you will have to pick from among a set of suboptions. Again, looking at Microsoft Exchange Server, you can build direct server-to-server links on top of a native connector, an X.400 connector or a connector based on NT's dial-up Remote Access Server. Indirect links can be built over most messaging systems, such as SMTP and X.400 for example. Generally, direct connections make the most sense for all but the most remote of servers. Some direct connect options require continuous links and do not allow you to schedule server-to-server communications. The Exchange Server native connector falls into this category. Others allow for discontinuous or dial-up like, scheduled links. The Exchange Server X.400 connector is one of these. Indirect links are best used to add redundancy by adding backups for direct l inks. They are also useful for connections to servers in locations where any kind of direct link might be too costly, too unreliable or both, such as those in developing countries for example. Some indirect links, X.400 for example, need not be continuous and can be scheduled. Others, SMTP, for example, must usually be continuous and cannot be scheduled. When linking groups of servers in different locations, you may have the option of allowing one server in each location act as the primary link for the location. In such a scenario, each primary link server communicates with other primary link servers, representing all of the servers at its location. This not only limits the number of cross-location server-to-server connects you will need, but also lets you build redundant links between locations by establishing multiple primary link servers per site. Selecting Networking Options For each e-messaging product-specific server-to-server connectivity option you choose, you also must choose a networking option. Above all else, choices will be based on expected server-to-server communication loads and cost considerations. If you expect heavy server-to-server communication loads, you are going to need high bandwidth network connections such as those provided by topologies like Ethernet, Token-Ring, T3, Fast Ethernet, FDDI, ATM and SONET. Full T1 will also work in many situations, but you should experiment to be sure. For low-load links, especially indirect connections, lower bandwidth networks are acceptable. These include dedicated dial-up, fractional T1 and ISDN. 10. Decide How You Will Link Your Organization to External E-messaging Systems As John Donne almost said, "No organization is an island." In fact, today no organization can afford to be an island. With the E-messaging Decade upon us, electronic messaging will increasingly become the primary means of communicating and doing business. Consider connections to sy stems outside your organization to be necessities, not niceties. The Internet and its SMTP mail standard are becoming quite popular today. Connecting e-messaging systems to the Internet is fairly easy. Modern SMTP sendmail emulators and gateways are multithreaded, robust and stable. Some support discontinuous, scheduled links using UUCP messaging services. However, most require continuous links and do not permit scheduling of connections. SMTP messages can be secured using the Privacy Enhanced Mail protocol, for example. The MIME standard provides good message body part differentiation and encoding. In planning, don't underplay the importance of X.400 connects, especially if your organization communicates with organizations outside the U.S.A. The X.400 suite includes the Electronic Data Interchange (EDI) standard. EDI supports electronic commerce and provides secure communications when using your messaging system for things like purchasing and paying for products and services. Yes, you can secure Internet mail communications, but X.400 is catching on, even in the U.S.A. Keep it in mind. Again, if your e-messaging software permits, use primary link servers for external connections. As with cross-location server-to-server links, this will let you limit the number of internal-to-external system connections and build redundant links. Here is GerCom's map with connections to external e-messaging systems. 11. Validate and Optimize Your Design Validation means assuring you have a system that guarantees message delivery, integrity and security. It also means assuring that the system you designed is versatile enough to handle the range of documents, messaging formats and applications your organization needs. Guaranteed Delivery Guaranteed message delivery comes with reliable e-messaging servers and reliable internal and external networks. To increase the likelihood of guaranteed delivery: Go for as much server fault tolerance and networking redundancy as your organization can afford. Use quality server and networking hardware and software inside. Buy outside networking services from stable, experienced, well-established providers. Monitor the health of your networks and be prepared to fix problems quickly. During the validation phase, send messages of all kinds through all of your connects and then check to see if they arrive intact. When problems arise, use message tracking tools available in your e-messaging system to catch wayward messages. Also, use whatever network and system monitoring tools your e-messaging system has to discover why a message didn't get through. Reliability is only one side of guaranteed message delivery. You also need e-messaging servers that are fast enough and networks that have enough bandwidth to move messages quickly enough to meet maximum delivery time parameters. If you specified that all messages should be delivered to all internal users within five minutes, now is the time to see if your e-messaging system is capable of performing up to spec. If not, you either have to give some on maximum delivery times or, depending on the source of the problem, come up with speedier servers and/or higher bandwidth networks. Message Integrity Message integrity means that messages arrive in the same form as transmitted. Problems with message integrity can often be traced to mismatched binary message part encoding and decoding. For example, a binary attachment to a message bound for the Internet is UU encoded by the sender, while the receiver expects MIME encoding. Assure that message encoding parameters for your e-messaging system are properly set for internal communications. If you can set encoding protocols for specific external addresses, be sure they are set to match each external recipient's decoding capabilities. If users can set encoding options, be sure they understand the consequences of changing an encoding parameter. Message Security Message security is a complex matter. As noted in the section on security, encryption and public keys often work only for messages sent to users inside an organization's product-specific e-messaging system. For messages destined for foreign e-messaging systems, think about add-on security services, like the Privacy Enhanced Mail protocol for SMTP-bound mail. You can try to validate message security on your own or with the help of a Certified Electronic Data Processing Auditor. If security is important to your organization, going with the latter is safest. System Versatility Be sure your messaging system supports message formatting capabilities and standards that let users send documents of all the types they will need from simple text to complex multimedia presentations. Don't rely on should-work assessments. As with everything in this section, be sure to do hands-on validation. On the applications side, make sure you have all of the electronic messaging-enabled functionality your users might need: forums, calendaring and scheduling. For custom app development, make sure the APIs and tools you need are there and working. Optimization When you have done everything to assure guaranteed message delivery, message integrity and security as well as system versatility, it's time for optimization. You optimize your design by looking for alternatives that can help improve your e-messaging system. The basic question is: Can I do it better, faster, easier? For example, you might want to consider implementing support for X.400 messaging even though your organization has no current need for it, simply because competitors are moving toward it. Optimization also can focus on reducing costs without compromising the quality of your syste m. For example, you might want to come up with alternative, perhaps lower cost options for connecting e-messaging locations or for realizing network redundancy. 12. Roll Out Your Plan Roll out doesn't mean dropping a whole production e-messaging system on your organization all at once. It means making e-messaging services available to specific systems people and users according to a carefully thought-out schedule. You should go through a testing phase with specific users. You might start in MIS, maybe just with yourself. Then you might move on to samples of users based on the groupings you uncovered in your needs assessment. Then move steadily onward until all users are up and running on the e-messaging system. The key is to make the e-messaging system available to all users as fast as possible without crashing your organization. Remember that roll out is an integral part of the e-messaging system design process. As you step through your roll out plans, be ready to change your design. If something doesn't work, change it as soon as you encounter it. Don't let things pile up to the point that change becomes virtually impossible. Whether you are in a test or production roll out phase, be sure to keep users in the loop. Get them committed to the e-messaging system. Let them know if and when they are going to be seeing the system's client. Explain to them how they can use the new client both to do what they are already doing and to get other tasks done. This is where user training comes in. Keep the MIS staff involved and informed as well. An e-messaging installation and implementation is a big deal for an MIS department. Over time, just about everyone in MIS will get involved with the system. MIS staff should understand and welcome the e-messaging system, not see it as a threat to their jobs. Train MIS personnel as data processing colleagues, not just end users. You don't have to tell everyone in MIS everything there is to know about the system. But, be sure to talk to them about both server and client basics from a more technical perspective. For the curious, documentation and third-party books can be used to supplement basic training. End Return to beginning November 15, 1996 Print This Page E-mail this URL