Planning Storage Groups

In most new implementations, whether they are migrations or clean installations, planning is the part that gets the least attention and yet deserves the most. We can’t emphasize enough that poor planning leads to poor implementation and increased administration over the long term. If you were to record the types of support activities you perform each day for a month and then review them, you might find that 50 percent or more of them could have been avoided with better planning and implementation. I know you’re thinking that you don’t have the time to do good planning. But if you don’t, you’ll end up using the time you saved dealing with the unforeseen troubles caused by your migration to Exchange Server 2003.

Real World—Network Administration at Its Best

We know of one Exchange administrator who faithfully accomplishes the following activities on a regular basis. He developed this list by taking a thorough look at his daily activities and proactively planning ways to avoid common “fires.” Needless to say, his Exchange network runs smoothly and he feels ready for any disaster that might occur. To some of you, these tasks might seem like overkill. But we would encourage you to withhold your judgment as you examine these steps. We think this is nothing less than outstanding administration.

On a daily basis, he checks his logs—all of them. He checks the application, security, system, directory, and other logs. If he sees any warnings or cautions, he checks them out and resolves them that day, if possible. He also checks his backup software logs each day to make sure the backups worked. He performs an incremental backup every day except Friday. In addition, he uses a monitor or critical services on his Exchange servers and sends bounce messages every hour to his company’s regular vendors and customers. In all, eight Internet SMTP servers are sent bounce messages. If the link goes down, he often knows about it before anyone else and can troubleshoot it and (sometimes) fix it before his users even know something is wrong. (To learn more about Link Monitor and Server Monitor, see Chapter 27.)

On a weekly basis, he performs a full backup of all of his servers and makes sure on Monday that they were successful. If not, he starts another full backup on Monday as he is leaving work. He also checks his antivirus software for updates and uses their network software to update his servers and his users’ workstations.

Every month, he runs a series of System Monitor charts, logs the activities, and then prints a report for each server, placing it into an ever-expanding notebook. These charts measure the health of his servers and run for three days at 10-minute intervals. With them, he is able to predict how the addition of a service or a new group of users will affect each of his servers. And when he requests new hardware, he has the numbers and the credibility to back up his request.

In addition, each month he performs a trial restore for each tape backup device that he uses. Since he performs backups on three different servers, he does three trial restores. Here is how he does it. He takes 15 percent of the information that is currently being backed up and copies it to another location on the same server. Often, he’ll create a temporary folder named Test. Then he backs up this temporary folder, noting the size and number of files. After the backup and verify operation is complete, he deletes the Test folder and then restores it from the tape backup. When the restore is complete, he compares the size and number of files in the restored folder to those in the original Test folder. If they match, he knows his tape backup system is working. If they don’t match, he has some troubleshooting to do.

Once a month, he also restores his Exchange databases to an offline server that is configured in roughly the same way as his production server. He then makes sure that those databases work on the offline server. This exercise has given him the confidence to know that he can do a solid restore quickly and efficiently, and the knowledge that his backup system really is working. The time to learn how to restore your Exchange databases is not when the storm is raging and you’re on the phone with Microsoft technical support. It’s better to learn when everything is calm and you can make mistakes with an offline server.

Also, every four to six weeks, he offers user training, usually on topics that have dominated his support calls. This type of “customer service” approach has led to a steady decline in help desk calls because he has developed smarter users who can perform some very basic troubleshooting themselves, such as making sure that everything is plugged in or that the printer is on line.

On a quarterly basis, he drains his uninterruptible power supply (UPS) batteries and makes sure that his UPS software cleanly shuts down his servers. It’s better to find out that your UPS software isn’t working during a test than during a power outage. A good way to corrupt your Exchange database is to experience an unexpected power outage and have your UPS cut power to your Exchange server instead of shutting it down cleanly.

Moreover, on a quarterly basis, he checks for firmware updates and revisions for all of his servers. If there is a new update, he installs it. For his users, he’ll check for updates or service packs for the various applications that his firm uses. If new updates or service packs have been released, he tests them with a few trusted users and, barring anything negative, pushes the updates out to the rest of his network. Finally, he checks the cooling fans on all his servers quarterly to make sure they aren’t getting weak.

Because of his good planning, he has the trust of his superiors. He has taken the time to tell them what he is doing and why. Consequently, he has been able, over time, to implement many standards that have contributed to a smoothly running network. Being proactive in his planning has helped him achieve a situation in which he spends a good portion of his time being proactive about the upcoming changes his network will experience instead of just putting out fires.

Planning for Disk Space

Let’s take a look at some planning issues. We’ll trust you to not skim this section. Since this chapter focuses on storage groups, we’ll confine our discussion to planning for disk space, multiple databases, and multiple storage groups. (For a broader look at how to plan for Exchange Server 2003, refer to Chapter 5, “Assessing Needs,” and Chapter 6, “Planning for Development.”) When planning disk space capacities for your Exchange 2003 server, you need to consider several key factors:

• The number of users to be housed on a given Exchange server

• The types of users to be housed on a given Exchange server

• The average size of an e-mail and an attachment, and the number of attachments that your users will need to send and receive

• The number and size of public folders

The next two sections describe how to calculate the disk space needs of your Exchange server.

Calculating Disk Space for E-Mails and Attachments

Messaging activity by your users is going to be difficult to forecast. Some users send and receive only a few e-mails each day. Others are at the opposite end of the spectrum, sending and receiving lots of e-mails each day, some with large attachments. Obviously, given the same hardware specifications, you can house more light users in a single mailbox store than you can heavy users. Although it might seem trivial to do so, it’s best to develop some type of classification system for your environment and then run the numbers to determine how many users you want per store, per storage group, and finally, per server. If you can get a semi-accurate picture of your current messaging usage, you’ll be better able to predict hardware and storage group needs.

A good way to do this is to pick a random sample of your users—at least 15 percent—and then conduct an audit of their current e-mail usage. Be sure they are saving copies of their sent e-mails in the Sent Items folder so that you can get an idea as to how many e-mails they are sending each day and the size of their e mails. You can also see how many e-mails had attachments and, by opening the e-mails, you can see the sizes of the attachments. Security concerns might keep you from getting the information you need from some users, and in those cases you can give them a short survey to fill out.

Once you’ve collected your data, you need to analyze it. This part simply involves running some numbers. Consider this example: Assume that you conducted your analysis on 45 users (out of 300 users) over a 60-day period, and you find that the average number of e-mails per day for each user is 14, with 2 attachments. Let’s further assume that the average size of each e-mail is 1 KB and the average size of each attachment is 200 KB. The numbers would look like this:

• 14 e-mails 1 KB = 14 KB per day in e-mail.

• 2 attachments 200 KB = 400 KB per day in attachments.

• Total average disk space usage: 828 KB per day (414 KB for the store, 414 KB for the transaction logs).

• 828 KB 300 users = 248,400 KB, or 248.4 MB, of disk space per day for all 300 users. Over a two-month (60-day) period, there will be 44 working days, so 10,929 MB, or 10.9 GB, of disk space will be needed.

This final figure of 10.9 GB is somewhat misleading because the transaction logs will not be retained forever and some of the e-mails will be deleted. Eventually, the ESE will delete the old logs, freeing up disk space to be used again by the transaction logs. Therefore, let’s assume that the ESE keeps only a week’s worth of logs, or 5 414 KB = 2070 KB. Thus, after two months of activity, you will need only 5,466,870 KB, or 5.4 GB (44 days 414 KB average usage 300 users, plus 2070 KB for the logs) of disk space to run Exchange 2000 Server.

We’re not finished yet. All we have established is the amount of disk space needed to record e-mails and attachments. We still need to look at public folders and backup throughput.

Calculating Disk Space for Public Folders

To illustrate how to determine the space needed for the public folders, let’s assume that each user posts an average of three documents per day to your public folders, each with an average size of 6 KB. (Although this document size might seem large, refer to Chapter 2’s discussion of storage architecture. You will see storage of multiple types of documents in Exchange happening more and more.) We would calculate the public folder disk space like this: 3 posts 300 users 6 KB 2 (because each post is recorded once in the store and once in the transaction log). This scenario comes out to 10,800 KB (10.8 MB) per day of disk space for your users to post to their public folders. Over 44 days, you will need 237,600 KB (237.6 MB) plus 27,000 KB for the transaction logs (3 posts 300 users 6 KB average size 5 days), giving you a grand total over a two-month period of 264,600 KB (264.6 MB) of disk space needed for your public folders. Thus, you would need 5.46 GB for e-mails and 264.6 MB for public folders, or approximately 5.7 GB of total disk space for a two-month period. We’re still not finished, however. We now need to see how to use these numbers in planning for our storage groups.

Planning for Multiple Storage Groups

Once you’ve gotten a handle on your disk space needs, you need to consider how many storage groups you need. One factor you need to think about is the varying priorities of the work your users do. Let’s assume that 20 of your 300 users perform work that is absolutely mission-critical. Perhaps they are sales staff who take orders over the phone or who process customer orders that are placed in a public folder that is exposed on your Web site. Let’s assume that if these users are down for even 15 minutes, your company loses in excess of $50,000. In this type of situation, you should consider splitting these users into two groups and hosting each group in its own mailbox and public folder store. Hosting them in their own storage group, however, is not necessary.

The reasoning behind this recommendation is that if the other databases become corrupted, these users could continue to operate without disruption because you can dismount and restore one or any combination of stores while another store runs in the same storage group. And if one group’s database needs to be restored, it would be a fast restore because it would be much smaller than the companywide database in which the other 280 users are hosted. In addition, since these users are spread over two databases, the other half of the group can continue to work and remain productive. Hence, plan your storage groups with disaster recovery in mind more than disk space usage considerations.

Planning for Backup Throughput

Another consideration when planning your storage groups is the type of throughput you need when you do a restore. Let’s assume that you have purchased a tape drive with a maximum throughput of 10 GB per hour, or 166.6 MB per minute. At that rate, restoring the databases from tape backup would take about 35 minutes, if all the users were housed in the same database. When you factor in the time needed to diagnose the problem, find the tapes, and do the backup, you can reasonably assume that your users would be without e-mail and public folders for one to two hours, depending on the nature of the problem and how fast you can get to a point at which a restore operation can be performed.

In some companies, being down for one or two hours is no big deal. In others, it could spell disaster. Therefore, you’ll need to determine how long your users can be without Exchange services while you are performing a restore. Discussions with your manager can help you formulate the amount of downtime that is acceptable in the event of a disaster.

Suppose that as a result of these discussions, you determine that no one is to be without Exchange services for more than 30 minutes. To plan how to stay within this maximum downtime, you would take the restore time you calculated in the previous section and divide it by the maximum downtime allowed by management policy. This calculation will determine the number of stores you’ll need to create on your Exchange server. To determine the minimum number of storage groups you will need, divide the number of stores by 5 (the number of stores per storage group).

In our example, we know that it will take 35 minutes to restore data for 300 users. However, this number reflects keeping data for only two months. Most companies keep data much longer than this. So, if in our running example, we set our data retention policy to a more realistic period of one year, we’ll need to multiply our previous numbers by 6 to gain an accurate restore picture for one year’s worth of data. Thus, restoring databases holding a year’s worth of information would take 210 minutes, or 3.5 hours. Now, how would you handle this? Well, you’ll want to be able to restore the databases within 15 minutes to give yourself plenty of time to meet your company’s 30-minute downtime policy. Therefore, you would need to create a minimum of 14 separate mailbox stores and 14 separate public folder stores (210/15). This assumes, of course, that the databases will be relatively the same size. If some databases turn out to be much larger than the restore time goal, it would be wise to create additional stores or move some users’ mailboxes to create store sizes that will meet your goals.

In this scenario, you would need at least five storage groups to accommodate 28 stores. Since we have a maximum of four storage groups per server, you’ll need two Exchange servers to accommodate these databases. It would be best to load balance the databases as much as possible between the two servers. Also, since the system uses one set of transaction logs per storage group, increasing the number of storage groups would prevent the buildup of a large number of transaction logs per storage group, although it would cause an overall increase in the number of transaction logs for the entire system.