- Mapping the Design Components
- Evaluating Different Design Options
- Active Directory Design Details
- Defining Storage Groups and Multiple Databases
- Defining Administrative and Routing Groups
- Designing Remote Access to Exchange 2000
- Exchange 2000 Support and Maintenance Tasks
- Case Study for SmallCompany Inc.
- Case Study for MediumCompany Inc.
- Case Study for LargeCompany Inc.
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Defining Storage Groups and Multiple Databases
Developing the database and storage group design should be part of the organization's overall storage strategy for the Exchange 2000 project. Before deciding on the configuration, make sure that it satisfies the goals and objectives defined for the overall storage strategy. Sample objectives may include availability and performance.
Storage Groups
A storage group is an Exchange 2000 feature that allows you to group databases into a common container that shares a single transaction log set. Unlike Exchange 5.x, which limited you to a single database for the mail store on each Exchange server, Exchange 2000 allows you to create multiple (up to five) smaller databases within the storage group. This concept provides the following benefits:
Efficient backup administration—The ability to group databases into a single common container that shares a transaction log set allows the backup administrator to back up an entire storage group and only have to write the transaction log once to tape.
From a database recovery perspective, the ability to create multiple smaller databases makes it possible for quicker backup restorations without impacting a significant amount of users.
NOTE
For backup and recovery purposes, Exchange 2000 only allows you to back up or restore one database at a time. However, it also gives you the ability to create multiple job sets to run parallel backups for multiple storage groups.
There are, however, limitations to the number of storage groups that a single server can host. Although the theoretical maximum number of storage groups per server is 15, the practical number of supported storage groups per server is 4.
Databases
Multiple databases have a direct relationship with storage groups, disaster recovery plans, and in some cases, performance and availability. The role that databases play within the storage strategy is dependent on the needs of the organization.
With Exchange 2000 there are two different types of databases. They are the .edb and .stm files. The .edb files contain information relating to the mailbox and public folder content. The .stm files contain information specific to multimedia content. This type of information is usually considered mission critical.
Each storage group contains one transaction log file. This file maintains the real-time records of all the transactions written to the databases within the storage group. This file becomes important when a storage group or a database fails and a recovery is required. The general restoration process involves restoring the latest backup of the failed database and then replaying the transaction log file. This provides the most up-to-date information prior to the database failure. For this reason, the transaction log file should be kept on a different physical drive set than the one used for the .edb and .stm files.
Planning Storage Groups to Improve Performance and Disaster Recovery
When planning the storage group strategy, the needs of the organization have a direct impact on the approach taken during the design phase. Each technology has both positive and negative attributes and based on predetermined priorities, one technology may be a better fit than another. The two technologies discussed in this section are Redundant Array of Independent Disks (RAID) and storage area networks (SAN).
There are three principal RAID configurations discussed. There are many more configurations; however, this section addresses the configurations most commonly used by most organizations.
RAID-0. RAID-0 is considered the most efficient of the RAID solutions because of its ability to write data to all the disks at once. This is done by grouping a set of physical disks into a single logical partition. Even though this is efficient, it is the least reliable of the RAID solutions. If one of the drives fails in the stripe set, the entire logical partition becomes unavailable.
RAID 0+1. RAID 0+1 is considered the best option when efficiency and reliability are most important. This is done by mirroring two RAID-0 stripe sets. When data is written to one stripe set, the information is saved on the mirrored stripe set. Even though it is efficient and reliable it takes twice the amount of hardware for this type of configuration.
RAID-5. A RAID-5 configuration is best suited for situations in which reliability is the primary concern and performance is not an issue. The RAID-5 solution is an alternative solution when the expense of a RAID 0+1 is above the budget amount set for the storage solution. It is similar to the RAID-0 solution. However, it allows for parity within the stripe set. The benefit of this configuration is that if one drive fails, the integrity of the logical partition is not impacted. Even if one drive fails, the RAID-5 drive set automatically rebuilds itself.
SAN, or storage area network, is a technology that uses a centralized data portal that resides on the network and allows servers to connect to it using either fiber channel or SCSI. The server has the ability to allocate a portion of the data storage to be used as its data repository. SANs have the additional benefits of performance and reliability that is found in RAID technology.
As stated earlier, database information such as the .edb and .stm databases are mission critical. For that reason, RAID-0 is not recommended because it does not provide fault tolerance. Instead, consider either storing these data types within a RAID 0+1 or RAID-5 configuration.