The Shortcut Guide to Exchange Server 2007 Storage Systems

by Jim McBee


The conventional way of planning for Exchange Server storage is to throw a lot of disk storage at the server and hope that is sufficient. Mail storage requirements continue to grow for even average users; these users place more and more capacity requirements not only on disk storage but also on disk I/O capacity. As current capacity requirements are exceeded, the storage system must provide scalability. The Shortcut Guide to Exchange Server 2007 Storage Systems, authored by Microsoft Exchange MVP Jim McBee, covers Exchange Server storage capacity requirement planning, the basics of using iSCSI SANs, and best practices for scalability and SAN operations.


Chapter 1: Choosing an Exchange Server Storage Platform

Designing a server infrastructure for an Exchange organization has a lot of small obstacles that sometimes stand between you and an optimal design. Picking the right server hardware, security components, antivirus software, and anti-spam software can contribute to the success or the perceived failure of a particular design. Choosing the right storage platform seems like a no-brainer, but this task is frequently one of the choices that IT professionals and Exchange designers get wrong.

Choosing storage seems deceptively simple because it merely seems like you need to get enough disk space to ensure that you can support the number of mailboxes and the maximum mailbox sizes that you are planning to support. Scalability, input and output (I/O) capacity, deleted items, deleted mailboxes, and recoverability are frequently overlooked as factors that contribute to storage system requirements. Often a choice to use direct-attached storage (DAS) disks leaves you without room to grow, but choosing storage area network (SAN) technology can dramatically increase storage costs, limit your options with respect to configurability, and be unacceptably complex to manage for many Exchange shops.

Whether running Exchange Server 2000 or 2003, or Exchange 2007, picking storage for an Exchange system is a balance between performance, disk space requirements, scalability, and cost. Although the specifics of picking a system between Exchange 2000, 2003, or 2007 may be slightly different, the principles and most of the factors you must consider remain the same. Although this guide will mostly focus on Exchange 2007, it will note places where particular factors may affect Exchange 2000 or 2003.

This guide will cover the basics of Exchange Server storage including frequent mistakes that are made when sizing a storage system for Exchange data and how to properly size iSCSI-based SANs to provide you acceptable growth and performance. This chapter will cover the basics of Exchange Server storage including:

• The types of data storage that Exchange Server requires
• The differences between DAS and networked storage
• Storage technologies that Exchange Server can use
• The basics of Exchange input and output (I/O)

Chapter 2: Sizing the Exchange Storage Platform Appropriately

To the uninitiated, planning for Exchange storage, choosing the right number of disks, and selecting the right storage platform seem like simple enough tasks—throw a few mirrored disks at a fast-enough server and you are done! Indeed, if you are planning the storage requirements for an Exchange 2007 server that will support 100 mailboxes, “throwing a few disks together” will more than likely accomplish your goals.

Why then do so many Exchange Server installations run out of disk capacity far before a company had planned? Why do users start complaining about bad performance after a few months of using Exchange? Why do some storage designs not mesh well with the rest of an organization’s storage plans?

Planning for Exchange storage can be a bit tricky in a few regards. The first is planning for storage capacity. The bottom line is that users will almost always ask for more storage than you really want to give them. In some cases, they may actually need more storage in order to efficiently do their job.

The second Exchange storage quandary is that even when the amount of storage that is required for email is calculated accurately, there is actually more overhead associated with Exchange Server data once you consider factors such as deleted information retention, full text index files, database white space, and transaction logs.

Chapter 3: Implementing an iSCSI Storage System

Chapter 1 covered some of the important Exchange Server concepts relating to databases and transaction logs as well as discussed factors that may influence your decision in choosing between direct attached storage (DAS) or networked storage such as a storage area network (SAN). Choosing the right platform on which to store Exchange Server databases and transaction logs will help you to support the necessary growth you will require for the future.

Many Exchange administrators view Exchange storage sizing as merely adding the maximum amount of disk space that a server can support. For a number of reasons, this is not the best logic because you may be insufficiently estimating either the necessary storage capacity or the disk I/O capacity. Chapter 2 discussed two important concepts that are crucial when planning your disk system capacity; these include adequately estimating the amount of space the databases and indexes will consume and the disk space necessary to support transaction logs, and finally ensuring that the disk subsystem is capable of supporting the necessary I/O capacity. Chapter 2 also discussed the concept of I/Os per second (IOPS) and the importance of considering the expected disk I/O load the users will put on the disk subsystem.

This chapter will introduce the concepts of an iSCSI-based SAN storage system and discuss how to implement iSCSI from the Windows Server perspective when using the Microsoft iSCSI initiator. Understanding not only the implementation of iSCSI but also some of the concepts surrounding SCSI in general will help you to better understand how this works in your environment. Important topics in this chapter include:

  • Understanding the basics of iSCSI
  • Installing and configuring the Microsoft iSCSI initiator
  • Possible network designs for iSCSI implementations
  • Moving Exchange data and logs to iSCSI logical units (LUNs)
  • Hardware solutions and compatibility

Chapter 4: Best Practices for iSCSI Storage Systems

The previous chapters of this guide discussed the appropriate path for properly sizing your disks for both storage capacity as well as I/O capacity. This path has to include not only the maximum theoretical capacity you estimate you might need but also the maximum I/O load that you think you will need to support. This ensures that you run out of neither storage nor I/O capacity during the planned lifetime of your storage system.

Chapter 3 covered some of the basics of using the iSCSI initiator client on Windows 2003 to connect to a LUN that has been provided on an iSCSI target. That chapter just touched on the basics of implementing the iSCSI initiator.

This chapter will cover some of the ways you can avoid common mistakes that new system administrators make when they implement an iSCSI SAN as well as best practices you can follow to ensure that you avoid problems and run your iSCSI SAN system as efficiently as possible. Topics in this chapter include:

  • iSCSI volume (LUN) management
  • Operations and performance monitoring of iSCSI volumes
  • Ways to improve performance and storage availability
  • Backup recommendations