Hosting mail services for another company with Exchange 2000, part 2

If you're faced with hosting another company's mail services, you expect to deal with a number of hurdles. Exchange 2000 offers a host of new options to help you, and Brien Posey explains some of the less well-documented aspects of Exchange.

In “Hosting mail services for another company with Exchange 2000, part 1,” I discussed some of the issues you’ll face when hosting another company’s mail services. Some of these issues include scalability and security. You must consider many more factors, however, before you begin mail hosting for another company. In this Daily Drill Down, I’ll address some of the remaining concerns.

Storage groups
If you’re considering hosting multiple companies, one of the more natural methods is to take advantage of Exchange 2000’s ability to use multiple storage groups. As you may know, Exchange 5.5 used a single database to store every mailbox on the entire server. Likewise, Exchange 5.5 used a single database to store every public folder on the server. Exchange 2000 doesn’t have this limitation. In Exchange 2000, you could potentially place each company that you’re hosting into its own storage group. This means each company would have its own independent mail and public folder databases.

Keep in mind, though, that grouping companies at the storage group level may not be the best design for your network. The reason is that Exchange 2000 limits you to creating four storage groups per server. If you’re hosting medium-size companies with between 1,000 and 2,000 users, this may not be a big deal. After all, you may not want to host more than four companies of this size on a single server.

If you’re dealing with smaller companies or you have more than four companies you want to host (or if you just want to allow for future growth), then using the storage group organization method is a good starting point, but that’s not where you want to stop. Remember that each storage group can accommodate up to five mailbox and public folder stores. If you were to use a separate mailbox and public folder store for each company, rather than a separate storage group, you could host up to 20 companies per server rather than four.

Deciding which of these methods is right for your situation requires some thought. Organizing companies at the storage-group level rather than the mailbox and public-store level (or vice versa) involves some trade-offs. Organizing your companies at the storage-group level limits the number of companies you can host on a given server to four. This means every time you exceed the four-company limit, you’ll have to go out and buy another server before you can host another company. In spite of these limitations, however, there are some advantages to organizing companies at the storage-group level.

Separate databases
As you may recall, each storage group contains its own set of databases and transaction logs. These databases and transaction logs function completely independently from other sets of databases and transaction logs. This means a few different things for the companies you’re hosting. First, having separate databases pretty much guarantees security. Because each company exists in a different database, there’s very little danger of one company accidentally seeing another company’s data.

More important, though, having multiple databases means that in the event of a database failure, only one company will be affected. As long as the database engine and the core of the Exchange server is still functional, no company except the one with the malfunctioning database will be affected by the failure. Because separate databases are usually backed up separately, you can restore the database and perform the repair operation without ever taking the other companies offline. Your other hosted companies will never know there’s a problem.

Now, let’s consider what would happen if a database failed on a server that was hosting 20 companies. In such a situation, each database would contain five separate companies. This means that during a database failure, you’d still have 15 companies that were functioning, but you’d have five companies that were down. You’d probably have five times as many people calling you on the phone and screaming at you than if you had used a separate storage group for each company.

Even if you were hosting 20 companies, the four storage groups would still more than likely be backed up separately so that you could restore the five malfunctioning companies while the other 15 companies remained online. Keep in mind, however, that if a database contains five companies, it could potentially be five times larger than a database containing a single company. And as we all know, a database that’s five times larger takes five times longer to restore.

The way I look at this trade-off is that unless your budget dictates buying as few servers as possible, hosting more than four companies per server is a bad idea. If you host more than four companies per server, then when failures do occur, more people are affected and the problem can take longer to fix because of the sheer volume of data that’s being restored.

Hardware considerations
As you can see, it’s important to design a database structure that will properly fit the companies you’re hosting. Properly planning your hardware is just as important, however. I’ve seen too many situations where network engineers put a large amount of planning into the Exchange server architecture and then try to run it on mediocre hardware. A few years ago, I actually saw a company running an Exchange server with 150 mailboxes on a 486 with limited memory and disk space. This server was designed to dial in to the company’s Internet service provider through a 33.6 modem every 20 minutes and download mail for all 150 users. While the overall configuration of Exchange was set up very well, the mail service was painfully slow because of the hardware it was running on. In this particular case, this was a single company that was suffering the pains of insufficient hardware. Now imagine a more modern situation in which a company is trying to host multiple companies on hardware that’s simply not up to the task at hand. Every hosted company would suffer from performance problems.

Fortunately, there are some things you can do to make sure the companies you’re hosting don’t go through this situation. When planning the hardware for a hosted environment, remember that Exchange 2000 (and Windows 2000 for that matter) is a resource hog. Also, take into account that the more companies you’re hosting, the more resources you’ll need.

The first issue you’ll want to consider when planning your Exchange 2000 hardware is memory. So how much memory should an Exchange server that’s hosting multiple companies have? The answer is more. How ever much memory your server has, it can almost always benefit from more memory. A good starting point is 512 MB, but to determine how much memory you’ll actually need, you’ll have to use the Performance Monitor to study the server’s memory usage. As you plan your server’s memory, remember that the more Exchange services you have running, the more memory you’ll need. For example, if you’re enabling chat or instant messaging capabilities, you’ll have to have the memory to accommodate them.

You’ll also have to take into account that some types of hardware upgrades you might do to boost performance can actually reduce the amount of memory your server has available. For example, suppose you were going to cluster your Exchange server to improve performance or fault tolerance. The services that enable clustering actually consume quite a bit of memory. Therefore, if you decide to build a cluster, you’ll probably want to add some extra memory to compensate for what was lost.

A less dramatic, but less obvious, example is a situation in which you add a second processor to a machine. Many people assume that adding a second processor doubles performance. This isn’t the case. Adding a second processor boosts performance by only about 50 percent. The reason for this is that part of the processing power is used up by assigning tasks to a specific processor. In a multiprocessor environment, executable code doesn’t just end up at a specific processor for no reason—one of the processors has to tell the code which processor to go to. As with any other process that juggles data, juggling tasks between processors eats up some memory. Therefore, if you decide to add extra processors to your system, you might consider adding some memory as well.

So what’s the best hardware configuration for hosting multiple companies? It’s impossible to provide a general answer to that question because everyone’s network is different. People run different services on their Exchange servers. Likewise, everyone hosts different numbers of companies with a different number of users per company. Although I can’t tell you exactly what type of hardware to use, I can give you some pointers about what works well on Exchange servers that are in high-demand environments.

After considering your server’s memory, the next thing you should look at is your hard disks. Remember that if you’re hosting multiple companies, you could potentially have four storage groups online at any given time. This means Exchange will be constantly reading from and writing to multiple databases. Therefore, it’s important to have hard disks that are fast enough to keep up with the workload and reliable enough to keep from crashing in the middle of a database transaction. I recommend using a RAID 5 or a RAID 10 array. Both types of arrays offer great speed because they use multiple hard disks. A portion of each file is simultaneously written to each hard disk. Both of these RAID types also offer fault tolerance that will allow your server to keep running without data loss if a hard disk in the array were to go bad.

I also recommend looking into clustering your servers. There are essentially two types of clustering, but only one of these types is really suitable for Exchange. This type of clustering involves connecting two identical servers to a common RAID array. If a critical failure occurs on the primary server, then the secondary server takes over. The end users will never know a crash has occurred. When the problem is repaired, you can bring the primary server back online, and the secondary server will go back into standby mode.

Another recommendation is to use multiple processors. In spite of the additional overhead required to run multiprocessor environments, adding extra processors can significantly improve Exchange Server’s performance. If you’re hosting multiple companies, you’re going to need all the processing power you can get.

Finally, don’t forget to make sure you have plenty of bandwidth. Hosting 1,000 users from across the Internet isn’t the same as hosting 1,000 users in your own building. While you might be running 100-Mb Ethernet in your own building, you might only have a 1.544-Mb T1 line for your connection to the outside world. Therefore, even though the 1,000 users in your building may have very fast mail access, the 1,000 users on the outside fighting over the limited bandwidth of a WAN connection can have a very slow experience.

In this two-part series, I’ve explained that while there’s a lot of money to be made in hosting e-mail services for other companies, you must consider many issues before doing so. When planning your hosting strategy, you’ll need to consider such issues as security, bandwidth, hardware capabilities, fault tolerance, and disaster recovery.

Editor's Picks

Free Newsletters, In your Inbox