Lesson 1: Managing Data Storage

The principles of data backup and restoration are well known, but a good backup strategy is not in itself sufficient to ensure the survival of your organization in today's information-intensive business environment. Unless accompanied by a sound and well-understood storage strategy, a restore operation can only restore data that was up to date the last time it was backed up, possibly the day before. Few businesses can afford to lose a day's data. Also, backup and restore does not provide failover protection. A store needs to be taken offline, or dismounted, in order to restore lost data, and users are then unable to access their mailboxes until the restore is complete and the mailbox stores are mounted again. In this lesson, you learn how redundant disk systems can protect against data loss and provide failover support, and how correct management of your storage will enable you to restore lost data up to the point of failure.

After this lesson, you will be able to

• Explain the various disk systems that are used to provide disaster protection and failover support

• Explain the functions of the various types of files in which Exchange Server 2003 data is stored

• Determine which type of disk configuration is best suited to storing which type of file

• Explain how transaction log files can assist in restoring data up to the point of failure

• Explain the relationship between backup types and transaction log files

• Explain circular logging and enable it, if appropriate

• Explain how storage area networks (SANs) are used to store Exchange data

Estimated lesson time: 60 minutes

How Exchange Server 2003 Manages Data

Exchange Server 2003 handles various data types, which have differing requirements and compete for storage resource. The most significant competition is between transaction log and database files. This lesson explains why these types of files do not coexist happily on the same disk and should whenever possible be stored on separate drives.

Exchange stores data using the Extensible Storage Engine (ESE) database structure. The Exchange store can be separated into transactions and messages. Messages are stored in .edb and .stm database files, and transactions are stored in transaction log files. In addition to messages, database files contain attachments, folders, rules, indexes, and everything else the store needs.

The log files and database files behave differently from each other. When a user creates a new message, the change is not immediately written to the database file because that would seriously limit performance. Instead, changes are written to log files that write the transactions sequentially to a numbered file. Data in a log file is written to the database later. Exchange creates a new transaction log file when the one it is currently using reaches 5 megabytes (MB) in size.

Log files are always written to in sequential order, while database files are read and written to in a random manner. Therefore, an Exchange Server 2003 server needs to be able to read and write randomly to a large database file, sending the disk drive heads back and forth among the platters, while simultaneously writing to transaction logs in a sequential manner. The patterns of disk usage are at variance with each other and this leads to a loss of performance, particularly if you have many users.

You need to place the transaction logs and database files on disk systems that do not compete and are optimized for the types of activity you expect. Placing the transaction log files and database files on different disk drives (or spindles) is an obvious step, but organizations of any significant size use disk arrays rather than single disks. You need to decide the disk configuration that gives the best balance of performance, data protection, and cost.

EDB and STM Files

The raw format of an e-mail message is usually the Multipurpose Internet Mail Extensions (MIME) standard. Some e-mail systems (such as Microsoft Exchange Server 5.5) convert incoming messages from MIME into Rich Text Format (RTF). Exchange Server 2003 (and Exchange 2000 Server) uses the simpler MIME format to reduce processor loads and stores those unconverted messages in .stm files.

As Simple Mail Transfer Protocol (SMTP) messages arrive on your Exchange Server 2003 server, they are "streamed" into the .stm files without conversion. If the message is destined for a user's mailbox, then the message-header information is stored in the Messaging Application Programming Interface (MAPI) tables in the .edb file. If a user opens the item using a MAPI client such as Microsoft Outlook 2003, then the header information is copied into the .edb database. If the user modifies the item, it moves into the .edb database.

Disk Arrays

The use of redundant array of independent drives (RAID) systems is well known and is reviewed only briefly here. There are software and hardware implementations, and these can vary between manufacturers. One supplier's RAID-0+1 can be another's RAID-1+0. We shall consider only the common implementations most used in Exchange Server 2003.

Note

Depending upon the book you read, RAID can also stand for redundant array of independent disks and redundant array of inexpensive disks. Microsoft expands the acronym as redundant array of independent drives, and therefore that term is used here.

RAID-0 Disk Striping

RAID-0 requires a minimum of two drives and implements a striped disk array. The data is broken down into blocks, and each block is written to a separate disk drive in turn. Input/output (I/O) performance is enhanced because you can read from and write to all the disks in the array at the same time. If you have many channels and drives, then you can expect a corresponding improvement in performance, particularly when data is striped across multiple controllers with only one drive per controller. This is a simple design and is easy to implement, and there is no overhead due to parity calculation and no loss of usable disk capacity.

However, RAID-0 is not fault-tolerant. Parity information is compressed data from one disk that is stored on another to provide failover protection. Not generating such information improves performance and lowers cost, but data is unprotected. In fact, a RAID-0 array is less reliable than a single disk. It takes only one disk to go down for all the data in the array to be lost. The use of RAID-0 should be avoided in mission-critical environments.

Exam Tip

Examiners have been tripping up unwary candidates for years by proposing RAID-0 as a fault-tolerant solution. There is no reason to believe they are going to stop doing so now.

RAID-1 Mirroring or Duplexing

In RAID-1, all the data that is written to one disk is also written simultaneously to a mirror disk. Thus if one disk goes down, the data is still available on the other. Duplexing is where you use a separate disk controller for each disk. This increases reliability because if one controller goes down, the other is still available. It can also improve performance because data can be written to both disks simultaneously. RAID-1 gives good read performance as data can be read from both disks at the same time.

Note

Some configurations and RAID controllers will support simultaneous writes with only one controller, but you will not get the same reliability improvements as you would with a dual-controller setup.

RAID-1 requires a minimum of two drives to implement. There is total data redundancy, so a rebuild is not necessary in the case of a disk failure. However, RAID-1 is expensive. You need to double the disk capacity to support the same volume of data. Also, it may not provide instantaneous failover protection, depending upon hardware and software configuration considerations and which one of a mirrored disk pair fails. Also, if one disk goes down, the data on the remaining disk is no longer protected, and software implementation of RAID-1 adds to the load on the processor, possibly degrading throughput at high activity levels. Microsoft recommends hardware implementation, preferably with hot-swapping facilities where a faulty disk can be replaced and brought online without powering down or dismounting the array.

RAID-0+1 Mirrored Stripes

RAID-0+1 consists of two striped arrays that are then mirrored. This gives the redundancy of mirrored disks combined with the performance benefits of striping. RAID-0+1 requires a minimum of four drives to implement. It has the same overhead as RAID-1; you need twice the disk capacity as a standalone disk to store the same amount of data. If a single disk goes down, a RAID-0+1 array becomes a RAID-0 array with no data protection. If a second disk goes down on the same side of the mirror, then your data is retained. However, if disks on both sides of the mirror fail, then your data is lost and needs to be restored from backup when the faulty disks are replaced.

Because only one disk in a striped array needs to go down to bring down the entire array, RAID-0+1 is inherently less reliable than RAID-1, with the same overhead. This, however, should be balanced against the enhanced I/O performance that it provides. Typically, a RAID-0+1 array is a hardware implementation that supports hot swapping.

RAID-5 Striping with Parity

A RAID-5 array writes data on disk stripes, but for every row of stripes, it allocates one stripe per disk to hold parity information, which is compressed information about the data in all the other stripes of the same rank on the other disks. The parity stripes are distributed on all the disks in such a way that if one disk fails, the data on that disk is held in compressed form in stripes on all the other disks.

RAID-5 requires a minimum of three drives to implement. It offers excellent read performance because all the disks can be read simultaneously. Write performance is good, but not usually as good as that of RAID-0, because parity information needs to be generated and written to the parity stripes (although in modern RAID-5 configurations, this is hardware-based and relatively fast). The configuration gives immediate failover protection. If a disk goes down, then the parity stripes on the other disks continue to supply the data needed to support users. However, that data needs to be decompressed on read and compressed on write, so there is a significant drop in performance. Also, a striped array with a failed disk offers no data protection. If a second disk goes down, then the data is lost and needs to be restored from backup. Therefore, a failed disk in a RAID-5 system needs to be replaced and the data regenerated from the parity stripes on the other disks as soon as possible.

RAID-5 is not as expensive as RAID-1, but there is some reduction in total capacity because disk space is needed to store parity information. In the worst case, with three disks, one third of the total capacity is used for this purpose. If four disks are used, then one quarter of the total disk space is needed for parity information, and if five disks are used, then one fifth of total capacity is lost, and so on.

Software implementations of RAID-5 significantly load the processor. Systems with software RAID-5 also are unable to boot to the RAID-5 set because Windows needs to load the drivers for RAID-5 before it can recognize the array. Microsoft recommends the use of hardware RAID-5 in an Exchange Server 2003 organization.

Storing Transaction Logs and Databases

On any Exchange Server 2003 organization of a significant size (say over 100 users), you should store the transaction log files on a different disk from the database files. Exchange Server 2003 writes transactions to the log in sequential order, appending new transactions to the end of the log. These writes generate I/O activity, and the disks on which you store the transaction log must support a heavy I/O write load. The disks that contain the databases experience read and write activity when users access items in their mailboxes or when the information in the transaction log is written to a database. This is a comparatively small amount of I/O activity, except on servers that host multiple directory-replication connectors.

Because transaction logs require high-performance disks, a RAID-0 configuration would be ideal, except that it provides no data protection. The loss of transaction log data may not seem as serious a matter as the loss of database data, because only the transactions that have yet not been written into the database files are completely lost. However, the loss of transaction log data curtails your ability to recover lost database information up to the point of failure. Transaction log data therefore needs protection. The use of RAID-0+1 for storing transaction log files is a reasonable compromise. If a sensible backup regime is implemented, the total size of all the transaction log files should not be excessive, and the cost of RAID-0+1 storage can therefore be accepted.

Mailbox and public folder data is essential to your organization and must be protected. There is no requirement for exceptional I/O performance like there is for transaction log files. RAID-1 gives very safe and reliable data storage. However, mailbox and public folder stores can be very large indeed, and the cost of RAID-1 may be unacceptable. In this case, RAID-5 will provide data protection and good read performance at a reasonable cost.

Real World: Don't Rely Totally on RAID

There is an unfortunate belief held by some organizations that, because they protect data by using RAID systems, they do not require backup and restore policies. This is not the case. There are ways of losing, deleting, and overwriting essential data other than physical disk failure. Data needs to be backed up regularly and archived either in a fireproof safe or off-site, or preferably both.

How Transaction Logs Protect Your Data

If you store your transaction log files on a separate hard disk from your database files, then you improve your overall disk performance, and you also have protection against loss of recent data. When a transaction is completed, it is written into the transaction log. Each storage group has its own set of transaction log files. Periodically, the information in the transaction log is committed—that is, it is written into the storage group's database file. However, that information is not deleted from the transaction log. Transaction logs are deleted only when you do a full online backup of all the databases in the storage group. You should not delete transaction log files manually. A checkpoint file is used to indicate which transaction log entries have been written to a database file.

Soft Recovery

If you lose the hard disk containing the storage group databases, you can replace the damaged disk and then restore the most recent database backups. If you then delete the checkpoint file, then an automatic log file replay of all transactions that occurred after the backup transfers the recorded transactions from the log files to the databases. This is known as a roll-forward or a soft recovery.

Hard Recovery

It is possible that transaction log files were backed up subsequent to the database file backup. Transaction files are typically much smaller than database files and are backed up more regularly. An incremental backup backs up all the information that has been written to the transaction log since the last full or incremental backup. A differential backup backs up all the transaction log files whether they have previously been backed up or not. Neither incremental nor differential backups delete the transaction log files, nor do they back up the database files.

If you have backed up transaction log files since the last full backup, you can perform a hard recovery. Hard recovery is the process of replaying transaction log files from backup medium after you restore a database from an online backup. After the hard recovery, if Exchange determines that additional log files are available on the server for replay, then a soft recovery process restores these additional log files into the restored database.

ACID Properties

Transactions are not written to the transaction log files until they are completed. Such transactions are said to have ACID properties, where the acronym stands for Atomicity, Consistency, Isolation, and Durability. Put simply, this means that a transaction is either completed or it is not. Uncompleted transactions are rolled back, so that no transaction is ever partially completed. Suppose, for example, that somebody is sending an e-mail message with a large attachment to one of your users, and connectivity is lost due to a hardware fault in your server. In this case, the transaction does not complete and is rolled back, so the message is queued on the sending server. If you fix the hardware fault before the message times out, then the message is delivered. If not, a non-delivery report (NDR) is sent to the sender. Both are preferable options to the message disappearing in transit or being delivered without its attachment.

Loss of Transaction Log Files

If you lose the hard disk containing the transaction log files, but not the disk containing the databases, then you do not have to restore any storage group data from backup. However, you cannot replay transactions that are recorded to log files but not recorded to the physical database files on disk. This means that you can lose data that is not preserved either in the log files or in the last backup. If your backup strategy includes differential or incremental backups, then you can restore the transaction log files from this backup, but you will still lose recent transactions. However, if you have a well-designed backup strategy, the total size of all the transaction log files should not be excessive, and neither should the cost of RAID-based failover protection.

Tip

You can minimize the time it takes to recover from a hard disk failure if you keep each of your Exchange storage groups on a separate hard disk or hard disk array. Then if only one disk fails, you need to restore only the storage group that is kept on the failed disk.

Circular Logging

Microsoft designed Exchange Server 2003 for the enterprise, but the software also works well in organizations that have few users. Circular logging is Microsoft's solution for companies that do not want transaction logs to use too much disk space. It can also be used where it is not essential to protect the information being transferred to a storage group, for example, in a Newsgroup server. Circular logging saves disk space by reusing transaction log files. Instead of accumulating a set of logs that contain all the transactions that have occurred since the last full online backup, circular logging marks a log file for reuse after an Exchange Server 2003 server commits transactions to the database. Typically, circular logging uses four (sometimes five) files, or 20 MB of disk space.

Suppose you are storing your transactions in log files E0000010.log, E0000011.log, E0000012.log, and E0000013.log. When all four log files are full, ESE will rename the log file E0000010.log to E0000014.log and start overwriting its data. The exception to this rule occurs when the checkpoint file is still pointing to E0000010.log, indicating that not all of the transactions in E0000010.log have been written to the database (and none of the transactions in the other logs). In this case, ESE creates a fifth log file (E0000014.log) and does not overwrite E0000010.log.

Circular logging is used where there is a shortage of disk space to store transaction logs. However, Exchange Server 2003 keeps transaction logs so you can recover transactions when you need to restore a database during a backup. If Exchange Server 2003 reuses the logs, then you cannot recover the old transactions. Do not use circular logging in an environment where data recovery is important.

Real World: Circular Logging

Circular logging is often used incorrectly in the real world. If an organization has no backup policy, or a badly designed one that does not implement full online backups, then transaction logs will eventually grow to fill the available disk space. Circular logging is not the answer to this situation; a good backup policy is. A transaction log takes up only 5 MB, which is not a huge amount given the current sizes of available hard drives. Unless your organization is very large and very busy (in which case you can afford the disk capacity), there really is very little excuse for having more than a few hundred MB filled with transaction log files.

Storage Technologies

There are several types of storage technologies that can be deployed with Exchange Server 2003. Your choice will depend on the size of your Exchange Server 2003 organization and how the vendor has implemented the solution.

Exam Tip

Microsoft defines a typical exam candidate as having at least one year of experience implementing Exchange Server messaging systems in environments supporting from 250 to 5,000 or more users. It is likely (but not inevitable) that questions will be asked about storage systems capable of supporting that number of users.

It is probable that an Exchange Server 2003 organization will use one of the following storage technologies:

• External storage array (ESA)

• Network attached storage (NAS)

• Storage area network (SAN)

External Storage Array

The ESA storage solution uses an external Small Computer System Interface (SCSI) drive cabinet to house multiple SCSI disk drives, usually configured as one or more RAID sets. SCSI cables connect the disk drives directly to an Exchange Server 2003 server. This type of storage provides good performance but has limited scalability. It needs to be managed on a per-server basis. Microsoft recommends that ESAs, otherwise known as direct attached storage (DAT), be used by smaller Exchange organizations.

Off the Record

Microsoft does not define "smaller." This is wise. An organization with 300 users, all of whom use e-mail as their main method of communication, might have more complex requirements than an organization with 1,000 users, most of whom seldom use email at all. As a very general rule of thumb: if you have 500 or more users, then start thinking about a solution more scalable than ESA.

Network Attached Storage

An NAS solution has its own network Internet protocol (IP) address rather than being attached to an Exchange Server 2003 server. SCSI or fiber channel connections attach the storage device to the Ethernet network. The Exchange Server 2003 server maps file requests to the NAS server.

Exchange Server 2003 has local data access and bandwidth requirements that are incompatible with NAS products, and Microsoft does not recommend NAS technology. However, some NAS devices can be directly attached to a Windows 2003 server and appear on the hardware compatibility list.

Direct Access Storage

Microsoft recommends that you use a storage area network (SAN) for the storage of your Exchange Server 2003 files in a medium to large Exchange organization. This configuration optimizes server performance and reliability. A SAN provides storage and storage management capabilities for enterprise data and uses fiber channel switching technology to provide fast and reliable connectivity between storage and applications.

A SAN has three major component areas:

• Fiber channel switching technology

• Storage arrays on which data is stored and protected

• Storage and SAN management software

Hardware vendors, such as Intel, IBM, and Conexion, sell complete SAN packages that include the necessary hardware, software, and support. SAN software manages network and data flow redundancy by providing multiple paths to stored data, and facilitates connectivity between multivendor systems with different operating systems, and storage products from multiple vendors. Although deployment cost can be a barrier, a SAN solution may be preferable because the long-term total cost of ownership (TCO) can be lower than the cost of maintaining many direct-attached storage arrays.

The following are advantages to implementing a SAN solution in your Exchange Server 2003 organization:

• Exchange Server 2003 requires high I/O bandwidth that is supported only by a SAN-attached storage array.

• Exchange Server 2003 requires that mailbox and public folders stores exist on a drive that is local to the Exchange Server 2003 server. This requirement is met by SAN solutions that connect to Exchange servers through a local fiber channel connection.

• SANs are highly scalable. As mail data grows and mailbox limits are continually challenged, you need to increase storage capacity and I/O rates. As your organization expands, a SAN helps you to easily add disks.

• A SAN lets you expand your Exchange organization by adding servers. You can connect multiple Exchange servers to multiple storage arrays and then divide the storage among them.

Practice: Managing Storage

In this practice, you create a storage group, dismount a data store, move the transaction log files, enable circular logging, and mount the store.

Exercise 1: Create a Storage Group

In this exercise, you create a storage group. The data in the user mailboxes in this group does not require to be restored to the point of failure in the event of a crash, and you can therefore enable circular logging. To create this storage group, perform the following steps:

1. Start Exchange System Manager.

2. Navigate to Administrative Groups\First Administrative Group\Servers.

3. Right-click Server01, click New, and then click Storage Group.

4. On the General tab of the Properties page, type My Storage Group in the Name box.

5. Click OK.

6. In Exchange System Manager, expand Server01, right-click My Storage Group, click New, and then click Mailbox Store.

7. On the General tab of the Properties page, type My Mailbox Store in the Name box.

8. Click OK. Click Yes to mount the store.

   Note

   You would typically enable circular logging (if required) and specify a new location for the transaction log files when you create the storage group. However, this practice simulates the management of a working storage group, which should be dismounted before changes are made.

Exercise 2: Manage a Storage Group

In this exercise, you dismount a storage group, specify a location for the transaction log files, enable circular logging, and mount the database. In a real-world situation, if you were enabling circular logging, there would be little point in moving the transaction log files, which cannot be used for data recovery once circular logging is enabled. The purpose of this exercise is to become familiar with the procedures.

To manage a storage group, perform the following steps:

1. Start Exchange System Manager.

2. Navigate to Administrative Groups\First Administrative Group\Servers\Server01 \Storage Groups\My Storage Group.

3. Expand My Mailbox Store and click Logons to check that no users are connected.

   Tip

   In this exercise, no users will be connected. In the real world, however, you should warn users that the store is being dismounted and ask them to disconnect.

4. Right-click My Mailbox Store, and then click Dismount Store.

5. A warning appears telling you that all users will be disconnected. Click Yes.

6. Right-click My Storage Group, and then click Properties.

7. On the General tab, select the Enable Circular Logging check box, and then click Apply.

8. Read the warning, and then click Yes.

9. Specify a new location for the transaction log files. This should be a different volume, preferably on a different disk drive or array. Figure 12-1 shows this procedure.

   
   Figure 12-1: Specifying a new location for the transaction log files

10. Click OK.

11. Read the warning, and then click Yes.

    Tip

    The warning indicates that all stores in the storage group will be dismounted to move the transaction log files. From this, you might deduce that you do not need to dismount any stores before starting the procedure. However, it is good practice to check for connected users and then dismount the stores before you start. This prevents users connecting to a store while you are specifying its properties.

12. The transaction log files are moved and My Mailbox Store is mounted automatically. Click OK to close the information box.

13. Click OK again to close the My Storage Group Properties dialog box.

Lesson Review

The following questions are intended to reinforce key information presented in this lesson. If you are unable to answer a question, review the lesson materials and then try the question again. You can find answers to the questions in the "Questions and Answers" section at the end of this chapter.

1. The Sales storage group database files are stored on a four-disk RAID-0 disk array. The transaction log files are stored on the same array. Circular logging is not enabled. You do a full backup on Monday night and an incremental backup on Tuesday night. On Wednesday at 3:00 P.M., one of the disks in the array fails. Which of the following statements is true?

   1. You cannot retrieve any data that was written to the array on Tuesday or Wednesday.

   2. You can restore the data up to the Tuesday night backup.

   3. You can restore the data backed up on Tuesday night and then do a roll-forward to restore data up to 3:00 P.M. on Wednesday.

   4. You do not need to restore data. It is on a fault-tolerant array.

2. Which storage technology typically has its own IP address?

   1. RAID

   2. SAN

   3. ESA

   4. NAS

3. Your transaction log files are held on a four-spindle RAID-0+1 disk array. Disks A and B form a striped volume, as do disks C and D. The two striped volumes are mirrored. Disk A experiences a hardware failure. While replacing Disk A, your assistant accidentally damages Disk B. How do you recover from this situation?

Lesson Summary

• If you store database and transaction log files on the same disk drive and that disk goes down, then you can only restore up to the last backup. If the transaction log files are on a different disk and circular logging is disabled, then you can restore database files up to the point of failure by using the last backup and the transaction log files.

• RAID systems can protect data and provide failover protection. The exception is RAID-0, which gives enhanced I/O performance but does not protect data.

• Microsoft recommends ESA disk storage technology for small Exchange Server 2003 organizations and SAN disk storage technology for medium and large organizations.