When I start calculating how much storage I need, I look at the factors that may influence the mailbox database (or databases) size. Let’s first review some of the factors that actually affect the recommended size of a mailbox. In this section, I’ll show you how to calculate how big the mailbox database might get in a worst-case scenario.
Figure 12.1 shows a conceptual diagram of an Exchange 2007 Mailbox server that is designed to support 1,000 mailboxes. I will explain the process I went through to estimate the storage required. In some cases, I picked a typical large drive size. Mailbox servers are by far the biggest consumers of disk storage; you must plan for a large amount of storage space and be prepared for growth.
I also take into account local continuous replication (LCR) in Figure 12.1 and thus have allo- cated disk space for these files. Ideally, transaction logs and the operating system are on dedicated RAID 1 spindles and the databases are on dedicated RAID 5 spindles. Even though I labeled this figure as having local drives, you could deploy the same configuration using iSCSI or SAN disks. Exchange servers holding the Mailbox server role consume the most disk space. When design- ing an Exchange system, administrators often fall short when they do not allow sufficient disk
ESTIMATING DISK SPACE FOR EXCHANGE DATA 343
space for mail storage and transaction logs as well as extra disk space. Often the disk space is not partitioned correctly, either. Here are some important points to keep in mind when planning your disk space requirements:
Figure 12.1
Disk configuration for an Exchange 2007 mailbox server
Operating system, page file, Exchange binaries RAID 1 - 72GB
Exchange transaction logs RAID 1 – 146GB Exchange databases and indexes RAID 5 - 2.6TB LCR Exchange transaction logs RAID 1 – 146GB LCR Exchange databases RAID 5 - 2.6TB Local disk drives
C:\
D:\
F:\ E:\
G:\
◆ Place transaction log files on a separate set of physical disks (spindles) from their corre-
sponding Exchange database files. RAID 1 or RAID 0+1 arrays provide better perfor-
mance for transaction logs.
◆ Allow for at least a week’s to 10 days’ worth of transaction logs to be stored for each stor-
age group. The estimated amount of transaction logs will vary dramatically from one orga- nization to another, but a good starting point is about 5GB of transaction logs per day per 1,000 mailboxes.
◆ Allow for 10 to 15 percent white space estimates in the maximum size of each of your
database files.
◆ Allow for 10 to 15 percent deleted item and deleted mailbox retention space in each
database file.
◆ Place replicated transaction logs and the backup copy of the databases on separate physical
disks from the source when planning for local continuous replication.
◆ Allocate enough free space on the disk so that you can always make a backup copy of your
largest database and still have some free disk space. A good way to calculate this space is to take 110 percent of the largest database you will support since that also allows you to defragment the database using ESEUTIL.EXE if necessary.
◆ Consider additional disk space for message tracking, message transport, HTTP protocol,
344 CHAPTER 12 SIZING STORAGE GROUPS AND DATABASES
◆ Make sure you allow for enough disk space to perform database recovery, such as to a
recovery storage group. This disk space is usually determined by the maximum size of your databases. I usually make sure I have enough extra disk space so that I can recover at least 20 percent of the databases on the server. So if I have 5 mailbox databases, I would want enough space to have 1 mailbox database in the recovery storage group. If I have 20 mailbox databases, I would want enough disk space to have 4 mailbox databases on the disk that have been recovered.
Let’s look at an example for a server that will support 1,000 mailboxes. Suppose we estimate that we will provide typical users with a prohibit send size warning of 500 MB and a prohibit send and receive limit of 600 MB. In any organization of 1,000 users, you must consider that 10 percent of them will qualify as some type of VIP who is allowed more mail storage; in this case, we will allow those 100 VIP users to have a prohibit send and receive limit of 2GB.
This gives us 540GB of mail storage requirements (600 MB times 900 mailboxes) for the first 900 users plus another 200GB (2GB times 100 mailboxes) for the VIP users. This is a maximum amount of mail storage of 740GB. However, this estimate does not include deleted items in a user’s mailbox and deleted mailboxes, so we want to add an overhead factor of about 15 percent, or about 111 MB, plus an overhead factor of another 15 percent (another 111 MB) for database white space. The white
space is the empty space that is found in the database at any given time.
So at any given time, for these 1,000 mailboxes, we can expect the total size of mail database storage (valid e-mail content, deleted data, and empty database space) to be approximately 962GB, but since we like round numbers, let’s average that up to 1,000GB, or 1TB.
In this example, let’s say we have decided that the maximum database size we want to be able to back up or restore is 100GB. This means that we need to split our users’ mailboxes across 10 mailbox databases and storage groups.
For the transaction logs, we estimate that we will generate approximately 5GB of transaction logs per day. We should plan for enough disk space on the transaction log disk for at least 50GB of available disk space, to cover 10 days’ worth of logs.
Next, since full-text indexing is enabled by default, we should allow enough disk space for the full-text index files. In this case, we will estimate that the full-text index files will consume a maximum of about 5 to 10 percent of the total size of the mail data, or approximately 100GB. If we combine the full-text index files on the same disk drive as the database files, we will require approximately 1.3TB of disk space.
Finally, on this server we are planning to implement local continuous replication, so we will need to plan for a separate set of spindles for the databases (1.3TB) and the transaction logs (50GB).
Anytime there is any doubt as to how much disk space you should include, it is usually a good idea to plan for more rather than less. Although disk space is reasonably inexpensive, unless you have sophisticated storage systems, adding additional disk space can be time consuming and costly from the perspective of effort and downtime.