Deploying Microsoft® Exchange 2000 with Dell™ PowerVault ...



Deploying Microsoft® Exchange 2000 with Dell™ PowerVault™ Storage Area Network (SAN) 4.0

Part I: Exchange Database Implementation and

Backup/Restore Study

Enterprise Systems Group (ESG)

Storage Systems Group (SSG)

Dell White Paper

By Richard Hou

Contents

Abstract 3

Introduction 4

Microsoft Exchange 2000 Architecture 4

Dell PowerVault Storage Area Network 6

Test Methodology 7

Workload 7

Hardware and software 7

Exchange Database Implementation 10

Backup and Restore Strategies 16

Backup 16

Restore 18

Conclusions 21

Contacts 21

Appendix A: Reference Documents 23

Appendix B: MMB2 Workload Definition 24

Section 1

Abstract

This paper provides a set of guidelines for deploying Microsoft® Exchange 2000 Server on Dell™ PowerEdge™ Servers in a Dell PowerVault™ Storage Area Network (SAN) environment. It begins with an overview of the Exchange 2000 architecture and summarizes key performance and scalability enhancements over its predecessors, then discusses the Dell Storage Area Network 4.0 architecture. A configuration guide on how to implement Exchange 2000 on Dell products is also presented, with considerations and suggestions on how to achieve better performance through performance monitoring and storage I/O planning. Lastly, guidance and relative performance metrics are provided for tape backup and restore operations, which should prove valuable as a customer planning reference.

Section 2

Introduction

As the demand for real-time messaging and information exchange increases dramatically, along with the globalization of the market, applications that can handle efficient messaging collaboration become more and more important to the enterprise. Nearly all companies depend on these applications for messaging exchange, group scheduling, electronic forms sharing and multimedia conferencing. Within these applications, Microsoft Exchange 2000 integrates all these functions into one single system. However, customers deploying Microsoft Exchange 2000 Server into an existing infrastructure will need to address several concerns, such as integration with the Active Directory, storage group design, data availability, server performance and scalability, and, most importantly, disaster recovery.

Dell has partnered with Microsoft for over 15 years. This relationship has helped the two companies join together to provide integrated solutions with high availability, reliability, scalability and performance. Microsoft Exchange 2000 on Dell’s leading edge PowerEdge Servers and PowerVault Storage Area Network (SAN) products not only provides redundancy, but also provides leading price/performance for small, medium and enterprise customers. Dell has developed a sizing tool, Dell Power Match for Exchange 2000 (), to help customers find the configuration that best matches their environment. This tool helps the customer pick the right server and storage products based on the number of users, storage per user and backup/restore information. This paper will go beyond the sizing tool and will discuss the issues mentioned above and present best practices for how to configure Dell servers and storage for Exchange 2000.

Microsoft Exchange 2000 Architecture

With significantly enhanced features and newly developed functions, Microsoft Exchange 2000 is a major revision of Exchange 5.5. Architecturally, Exchange 2000 does not use a self-contained messaging system like Exchange 5.5. Exchange 2000 separates many components and tightly integrates them with the underlying Windows 2000 operating system and Microsoft Internet Information Server (IIS). These improvements can reduce the overhead on the Exchange servers, enable consolidation of the users onto much fewer servers, and unify the network and messaging administration, all of which contribute to lower total cost of ownership (TCO).

Figure 1. Microsoft Exchange 2000 Architecture

Figure 1 shows the Exchange 2000 architecture and the implementation of the Exchange database. The key features of Exchange 2000 that bring scalability, reliability and availability include:

Active Directory Integration - User manipulation, e-mail addresses, distribution groups, and other directory resources are stored in the directory database provided by Active Directory, which is a directory service running on Windows 2000 domain controllers. This simplifies user administration and reduces overhead on the Exchange servers by offloading user authentication.

Multiple message database support - Unlike Exchange 5.5, which used one single database for all users, Exchange 2000 allows the message store to be divided into multiple databases that can be managed either individually or in a logical group called a storage group. The message database can be on one or more Exchange servers. Since every storage group can have its own transaction log, the repair or recovery of one database won’t affect other databases in other storage groups.

Reliable SMTP support - Exchange 2000 uses the Simple Mail Transfer Protocol (SMTP) as the native communication method between Exchange Servers for transferring and delivering e-mail. Compared with Remote Procedure Calls (RPCs), which previous Exchange server used for message routing, SMTP provides major performance and reliability improvements. With SMTP, Exchange 2000 Server is a combination of the Exchange Information Store and IIS 5.0. A high-speed, shared-memory interface named “Epoxy” is used as the interface between the two services. Epoxy allows services hosted within the context of IIS (including POP3, IMAP4, NNTP, HTTP/DAV, and SMTP) to access information in the Exchange 2000 store via their native protocols, which means they have direct access to the Information Store, or the Web Storage System.

Active/Active Clustering Support - Exchange 2000 has enhanced cluster support that enables all systems in a cluster to actively process message requests. If one system fails, all the workload can be redirected to the remaining node automatically while the failed server is being recovered. The end user won’t be interrupted and there is no need for a dedicated failover server.

Dell PowerVault Storage Area Network

Dell’s Storage Area Network (SAN) uses fibre channel and RAID (redundant array of inexpensive disks) technologies to provide the speed, flexibility, and data-storage capacity necessary to meet the performance requirements of today's complex server networks. Dell’s fibre channel storage subsystem can support large or small data storage networks. By employing long-wave fiber-optic cable between cascaded switches, servers up to 10 kilometers (km) from the shared storage array can access data as if it were directly attached. Fibre channel delivers up to 100 megabytes per second (MB/sec) of bandwidth for half-duplex configurations and up to 200 MB/sec for full-duplex configurations.

Besides the high data input/output (I/O) performance, Dell SAN also provides a high availability environment through the use of a redundant path from the front-end servers that share the storage equipment, to the redundant switch in between the storage subsystem and the servers. I/O access is assured if one component fails. Battery backup is used to increase the integrity of data written to the RAID controller caches.

Currently Dell provides two kinds of Fibre Channel Storage solutions to the market: Dell PowerVault™ 650F/630F and Dell PowerVault™ 660F/224F. The PV224F is a cost-effective fibre channel storage array that provides scalable, rack-dense RAID storage with up to 14 1” fibre channel drives in a 3U enclosure (1 rack unit = 1.75”). The PV660F is a PV224 with one or two RAID controller modules. The RAID controller modules in the PV660F can manage the 14 disks in the PV660F as well as the disks in up to seven PV224Fs, for a total storage subsystem of 4 terabytes (TB). Besides the current Fibre Channel 1 standard (which is 1Gbps throughout), the backplane and chassis are Fibre Channel 2 (2Gbps) ready. The PV660F RAID controllers support RAID levels 0, 1, 3, 5 and 0+1; Online Capacity Expansion (OLCE) and Online Virtual Disk Expansion (OLVDE). These features give the administrator flexibility to expand the storage capacity without affecting the end users. With all these unique features, Dell’s SAN makes a perfect candidate to take full advantage of Microsoft Exchange 2000’s new database architecture.

Section 3

Test Methodology

Workload

To simulate the user workload, the Microsoft Messaging Benchmark 2 (MMB2) specification was used to create the user database and Microsoft’s LoadSim program was used to generate messaging requests. Databases of 500, 1,000 and 2,000 users were created on a RAID 0+1 array with 8K, 32K and 64K stripe size. Backup and restore times based on different user environments were collected. Detailed information is provided about the MMB2 configuration in Appendix B.

Hardware and software

Two Dell PowerEdge servers were used in the configuration, with one Dell PowerEdge 6450 as the Exchange 2000 server and one Dell PowerEdge 4350 as the Domain Controller (DC) to serve Active Directory Services (ADS). Each server has redundant power supplies in case of hardware failure.

The PowerEdge 6450 Exchange server was configured with two Intel® Pentium® III Xeon™ 550MHz/2MB L2 cache CPUs and 4GB memory. Upgradeable to four CPUs and 8GB memory, the PowerEdge 6450 is a good entry-level application server for growing companies. The Exchange server was also running VERITAS® Backup Exec™ 8.0.

To reduce overhead on the Exchange server, the directory services were put on a PowerEdge 4350 with two Intel Pentium II 450 MHz processors and 2GB memory. This system was used to handle the user authentication and related directory services.

For the client simulation, ten Dell Optiplex™ desktop computers were used to create multiple virtual users for different scenarios.

One Dell PowerVault 660F and one Dell PowerVault 224F were used as the fibre channel storage subsystem for the Exchange database. The PV660F and PV224F were both populated with fourteen 1-inch 10K rpm fibre channel disks, and the PV660F used two RAID controllers, each with 512MB on-board cache. For storage subsystem connectivity, the Exchange server had two Qlogic QL2200 Host Bus Adapters (HBAs). Two Dell PowerVault 51Fs were used to create a switched fabric. Also, a Dell PowerVault 130T was used as the tape backup library, connected by a Dell PowerVault 35F fibre channel-to-SCSI Bridge.

Figure 2 shows the complete configuration tested, with a full redundant path for high availability:

Figure 2. Exchange 2000 Server Configuration

Table 1: Testing Software/Driver Version

|Operating System/Application/Driver |Version Number |

|Microsoft Windows 2000 Advanced Server |Build 2195 with SP1 |

|Microsoft Windows 2000 professional (for clients) |Build 2195 with SP1 |

|Microsoft Exchange 2000 |RTM release |

|QLogic 2200 Driver (W2K) |Version 7.05.07 |

|QLogic 2200 BIOS |Version 1.45 |

|QLogic configuration utility |Version 1.34 |

|QLDirect | |

|Array Manager |Version 2.7 |

|Storage Consolidation |Version 4.0 (Java 1.2.2) |

|Veritas Backup Exec |Version 8.0 |

Table 1 shows the software and drivers installed on the Exchange 2000 server. The following practices were followed for better performance:

• Install Microsoft Windows 2000 Advanced Server and Exchange 2000 on RAID 1 internal drives.

• Reconfigure the Page file to be on a different physical drive than the operating system.

• Change the server mode to “Optimized for Server Application”.

• Enable the /3GB switch from the boot.ini file when using 4GB memory or more.

(Also see for additional best practices).

Section 4

Exchange Database Implementation

Exchange 2000 Server’s database implementation is very different from its predecessors. Understanding the database architecture will not only help administrators design the database more efficiently, but also make the backup and restore processes more effective. To understand the Exchange database, a few concepts need to be clarified. First is the Information Store (IS), the central repository for all messages on a Microsoft Exchange Server. Information is typically maintained in two databases: the Public Information Store and the Private Information Store. Previous versions of Exchange had only one storage group, containing a single Private Information Store and a single Public Information Store.

In Exchange 2000 Server, the Information Store provides new methods of accessing Exchange data. With support for any Windows or Internet client and various APIs, Exchange 2000 exposes its data through MAPI, HTTP and Win32. Thus the underlying data can be accessed through a drive letter, web browser or via a universal naming convention (UNC) path. This turns the Exchange 2000 Information Store into a Web Store.

Exchange 2000 Server supports up to four Storage Groups with up to five databases per Storage Group. Each of the Storage Groups uses a common log file and runs as a JET/ESE (Joint Engine Technology/Extensible Storage Engine) service in the process store.exe. Figure 3 shows the database architecture for Exchange 2000. This implementation makes individual databases smaller, allowing for faster backups and restores and increased flexibility in managing backups.

[pic]

Figure 3. Exchange 2000 Database Architecture

To understand how to design an Exchange database, the I/O nature of different RAID levels and the Exchange Server Information Store configuration must be understood first.

Table 2: I/O nature for different RAID levels

|RAID Level |I/Os Per Transfer |

| |Read |Write |

|RAID 0 |1 |1 |

|RAID 1 |1 |2 |

|RAID 5 |1 |4 |

|RAID 10 |1 |2 |

As shown in Table 2, although RAID 1, 5 and 0+1 all provide redundancy, their I/O performance is different. All use the same amount of I/O per read, but for every logical write, RAID 5 will use four physical I/Os for the operation, whereas RAID 1 and 10 will use two. This means if the database is write intensive, RAID 10 will provide better performance than RAID 5.

Table 2 is also helpful when calculating the number of drives in the RAID array. Seagate IV 10K rpm drive or 15K rpm drives can be used in the PowerVault 660F/224F. Generally 100 random I/Os per second can be expected from the 10K rpm drive. By monitoring the current messaging environment or setting up a pilot test, data can be collected from the Microsoft Performance Monitor object “PhysicalDisk” under “Read/sec” and “Write/sec”. If RAID 0+1 is used for the configuration, the following formula can be used to calculate the number of drives in the RAID:

Number of drives = 2 x {[Read/sec + (2 x Write/sec)]/(I/Os per second per drive)}

Table 3: I/O profile for Exchange 2000 database file and backup software

|Exchange Database file |VERITAS Backup Exec |

| |Mailbox Store (.edb)|Streaming Media Store |Transaction Log |Exchange files being backed up |

| | |(.stm) |(.log) | |

|I/O size |4KB |32 - 64KB |4KB |64KB |

|I/O pattern |Synchronous Random |Synchronous Random |Synchronous |Synchronous Sequential |

| | | |Sequential | |

|Read/Write |60/40 |60/40 |100% Write |100% Read or Write |

| | | | |based on the operation |

I/O Characteristics of the Exchange database file and the VERITAS Backup Exec (used as the tape backup application in our testing) are shown in Table 3. Although Exchange 2000 Server uses random I/O and 4KB transfer size, VERITAS Backup Exec uses 64K sequential read/write to backup/restore data. Therefore the performance of 64KB sequential read/write should be considered equally with 4 KB random read/write when choosing the RAID level for the mail server.

In Figure 3, the Transaction log files are labeled as “Uncommitted entries”. This is because the current database is actually a combination of the database file plus the uncommitted log file. The transaction log can be thought of as a copy of the memory content. Therefore, the transaction logs are important since they reflect what will be changed in the database and should be placed on a reliable and high performance RAID array. Transaction log files use write-ahead to write the data sequentially to the log files before they are committed to the database. Efficiency of the write is improved through the use of a write-back cache. The Dell PowerVault 660F provides onboard cache of up to 512MB per RAID controller. The cache is write-mirrored protected when the partnership is enabled and configured as “Normal cache mode”. RAID 0+ 1 is recommended for the transaction log with the write-back cache enabled. The configuration to enable the write cache will be discussed in the following section.

The goal in tuning the Exchange database performance is to decrease response time yet support more users. The I/O pattern for the Exchange database (random reads and writes with about a 60/40 split) is different than that of the transaction log. Although read cache is not significant for database access performance based on this pattern, use of the write cache will lower response time. The RAID controller in the PowerVault 660F does the read/write cache distribution dynamically. To support more users, more spindles need to be included in the disk array for multiple concurrent user requests. Currently Dell SAN 4.0 with PV660/224F supports up to 16 drives in each virtual disk.

In addition to the need to increase spindle count to increase number of concurrent supported users, other factors are involved in sizing the Exchange database. First, it is necessary to figure out how many users will be supported and how big the user’s mailbox can grow. This will determine the total space needed for the database file. Then, per the Microsoft recommendation, double the capacity of the database file. There are some benefits for doing this. First, disk maintenance like defragmentation can be performed quickly without copying the database file to a separate drive. Secondly, the extra space will help to reduce the time required to restore the database from tape. After the total capacity is decided, divide it by the capacity of a single drive to determine the number of drives required. For RAID 0+1, this number should be doubled and for RAID 5, add 1 more drive. Dell SAN 4.0 with PV660F/224F supports the Online Capacity Expansion (OLCE) and Online Virtual Disk Expansion (OLVDE). Capacity and extra spindles can be added to the array without stopping the environment.

The next things to determine are the hardware stripe size and NTFS block size. By default, PV660F uses a 64KB stripe size for the RAID, which provides optimum performance for most applications. In this study, 8K, 32K and 64K stripe sizes were used for the Exchange Database. We found that 32K stripe size performed better than 64KB in the Exchange environment. Figures 4 and 5 show the LoadSim score and the I/O latency for different configurations.

Figure 4. LoadSim Score for 2000 users Figure 5. I/O performance for 2000 users

The default allocation unit size that NTFS provides depends on the volume size. Matching the allocation unit size with the amount of data that the application typically transfers to and from the disk will lower disk subsystem overhead and gain better overall performance. Figure 6 shows the performance monitor result from the lab test. “Average Disk Bytes/Transfer”, “Average Disk Bytes/Read” and “Average Disk Bytes/Write” from the “PhysicalDisk” object on both log files and database files drives were collected. It shows the average transfer size is about 4KB. This will be the block size for NTFS file system.

[pic]

Figure 6. I/O profile Exchange 2000 database and log file

Table 4 summarizes the recommended configurations for a RAID level, stripe size and NTFS block size for the different files in the Exchange 2000 database. The number of spindles was decided by the size of the tested database. (Exchange users should determine this for their own specific environments based on the algorithm above). For these tests, the .edb file and .stm file were placed on the same drive since the MMB2 workload is a Microsoft Outlook-based user workload that will simulate MAPI users without touching the .stm file (streaming media store). If part of the Exchange workload involves streaming media, Dell recommends placing the .edb file and .stm file on two different physical drives since the I/O of these two files are different.

Based on observations from testing, the final configuration for the database is one Storage Group with two databases. The first database contains 100 user mailboxes, and the second one has 1900 users. The reason for splitting the database in two will be discussed in the Backup/Restore section.

Dell SAN 4.0 and the PowerVault 660F use the Dell OpenManage( Array Manager for the storage subsystem management. To configure the RAID controller card, first start the Array Manager, expand the PV660 system on the left panel of the console, expand the “Physical Array”, right-click on the controller and click “Controller Options”. The following changes were applied to improve performance:

• Conservative Cache Mode disabled. By default, this is enabled which means the controller cache is not being used for I/O buffering.

• Current Queue Limit = 192. This counter is used to limit the total number of I/O transactions that can be issued simultaneously from the Host Bus Adapter to the controller.

• Use a SES communication drive as a hot spare. A SCSI Enclosure Service (SES) communication drive is in either slot-1 or slot-2 of the PV660F enclosure. There is only one SES communication drive per enclosure. Making the SES communication drive part of the disk group might cause performance degradation of the disk array (where the impact would lessen with more disks in the array). Therefore, it is better to leave this drive as a hot spare if not needed in the array.

Table 4: Recommendation for Exchange 2000 Database

|Exchange Database and Log File Layout Parameters |

|　 |Mailbox Store (.edb)|Streaming Media Store |Transaction Log (.log) |

| | |(.stm) | |

|RAID Level |RAID 0+1 |RAID 0+1 |RAID 0+1 |

|Stripe Size |32KB |32KB |32KB |

|NTFS Block Size |4KB |4KB |4KB |

|Number of Spindles |12 |4 |

|Cache Policy |Write Cache Enabled |Write Cache Enabled |Write Cache Enabled |

Section 5

Backup and Restore Strategies

Disasters that would cause loss of data include both hardware and software malfunctions. In addition to the fault tolerance provided by configuring Dell PowerEdge Servers and PowerVault Storage Area Network components for redundancy, it is necessary for a customer to have a robust backup strategy to protect key data. In the case of Exchange, this includes the public and private information stores. A well-designed backup/restore strategy can help the customer get their Exchange environment back to normal quickly and efficiently. The following section will discuss this strategy for disaster recovery. Other factors, like UPS or clustering will not be discussed.

Recovering Microsoft Exchange 2000 Server data efficiently requires a good understanding of Exchange 2000 database technology. As discussed above, the Exchange 2000 model supports a single server running multiple private and public databases. The use of multiple database files (MDBs) makes it possible to backup and restore separate databases independently without shutting down the rest of the messaging system.

Backup

The following Exchange 2000 and Windows 2000 files need to be backed up:

• Information Store including Private Information Store, Public Information Store and Transaction logs.

• Windows 2000 operating system Registry for service-related and configuration information.

• Other files and directories used by Exchange 2000, such as the MTADATA directory that contains messages and transits through the MTA, and customized scripts for scheduled jobs.

• Application and backup software, such as Exchange 2000 itself and VERITAS Backup Exec.

Exchange 2000 Server supports different types of backups: full, copy, incremental, and differential. The type of backup to perform depends on the importance of the data. Each of the backup types has advantages and disadvantages in terms of data storage, performance, and time requirements. There are two general backup methods: online and offline. Online backup does not affect users’ requests and Exchange processing while the backup job is running, whereas offline requires that Exchange be shut down. Table 5 describes different methods to backup Exchange server.

Table 5. Exchange 2000 Database Backup Method

|  |Backup Type |Definition |Advantages |Disadvantages |Circular Log |

| | | | | |Requirement |

|Online Backup |Full |Entire Information Store |Easy to schedule and |Adds overhead to server|Can be disabled or|

| | |will be backed up. |restore |performance and takes |enabled since |

| | |Transaction logs will be | |more time. Requires |backup software |

| | |backed up and then purged.| |most tape space. |deletes the log |

| | | | | |files. |

| |Copy |Same as Full backup, |Won't affect incremental |Requires large amount |Can be disabled or|

| | |except the transaction |or differential backups. |of storage space, |enabled |

| | |logs will not be purged on|Can be very useful for |especially when the | |

| | |the drive. |data archive. |circular log is off. | |

| | | | |Usually not a primary | |

| | | | |backup method. | |

| |Incremental |Back up a subset of the |Minimal affect on server |Complex restore |Must be off |

| | |Information Store based on|performance. Requires |process. Follow the | |

| | |changes make to the |minimal storage space |last normal backup -> | |

| | |database since the last |since only the log files |every incremental | |

| | |full or incremental |are written to tape then |backup path. | |

| | |backup. |purged from disk. | | |

| |Differential |Similar to incremental |Minimal affect on server |Does not remove |Must be off |

| | |backup without purging the|performance. Requires |transaction logs thus | |

| | |log files from the disk. |minimal storage space and |needs more space than | |

| | | |easy to restore. |incremental backup. | |

|Offline Backup |Requires all services to be stopped before the backup starts. It is a file-based backup and the backup |

| |administrator needs a good understanding of which files should be backed up. |

Exchange-aware backup software needs to be used for backup to tape. In these tests, VERITAS Backup Exec 8.0 for Windows NT/2000 was used. VERITAS Backup Exec 8.0 is part of Dell’s SAN backup solution and offers comprehensive data protection and automated disaster recovery. (It also delivers the automatic cluster failover for backup and open file protection for the Windows 2000 environment that will be examined in Part II of this study, Clustering on Exchange 2000 with SAN 4.0). Within the online backup methods, full backup is the preferred type of backup since it makes full backup copies for Exchange database files and Exchange log files. Also it deletes those transaction log files that contain transactions committed to the server database. It is easier to restore from a full backup because it usually involves only one backup tape.

Offline backup is a normal file-level backup after the services are stopped. This kind of backup can be performed with any backup application. In addition to requiring Exchange be stopped, the disadvantages of offline backup are that it won’t automatically back up all the log files and that the job needs to be scheduled very carefully to cover all the necessary files for the restore. Therefore it is not the recommended method unless the online backup could not be scheduled due to technical reasons.

There are a few important points to consider before designing the backup/restore plan:

• Always try to include the Windows 2000 Registry. Having a backup of the windows Registry makes it easier to replace the Registry during a restore.

• Although databases can be backed up individually, Dell recommends backing up an entire storage group at one time so that the transaction log file with each storage group will only be backed up once.

• Only one backup or restore process at a time can happen in a single storage group. Multiple processes can be scheduled for databases within different storage groups.

The testing focused on how long it took to perform online backup/restore while MMB2 workloads of 500, 1000 and 2000 Exchange users were running. A Dell PowerVault 130T tape backup library connected to the PowerVault 51F fibre channel switch through a PowerVault 35F SCSI-fibre channel bridge. Since the restore time will most often define the Service Level Agreement (SLA) time, these tests try to show the restore time with different numbers of users. In addition to backing up the main database (with 1900 mailboxes) to tape, the separate database file (with 100 mailboxes) was independently backed up to local disk using Windows 2000/Exchange 2000. This smaller, easily restored set of mailboxes could be used for the enterprise’s most critical set of users.

Figure 7 shows the different backup times for varying number of users. From the data, a storage group with 2000 users can be backed up within 2.5 hours. To avoid long backup times, extra users should be put into separate storage groups on a separate disk array.

[pic] Figure 7. Backup times to tape for 500, 1000 and 2000 users, and to disk for 100 users

Restore

Different types of disasters might occur which require different modes of recovery. The process might include restoring a single mailbox, database or storage group, or the restoration of the entire Exchange 2000 server with a previous configuration. For this test, the focus was on the length of time to restore different databases with different numbers of users while the Exchange 2000 server was still functional. This is a relatively easy process compared with recovering the whole system. Some rules of thumb will be given at the end of this section based on best practices and studies.

To restore the databases, Dell recommends stopping the Exchange application and dismounting all the databases to be restored. The Web Storage System must be running. One of the most important recommendations is to make a copy of the current database even if it might look corrupted. Until the database is restored and verified, do not delete this copy. In case the restore fails, the copy might be used for repair.

When the restore starts, Exchange server will dynamically create a storage group to save the database and transaction log files from the backup. During restoration, the transaction logs are applied to the database in the restore storage group. After recovery, Web Storage System mounts the recovered database into its original storage group. As discussed above, only one backup or restoration process on a particular storage group can run at a time. To run the backup or restore simultaneously, multiple storage groups need to be configured, which is why multiple storage group are recommended when supporting large numbers of users. By splitting the mailboxes into multiple databases, a server can support more users without each backup/restore process taking too long.

Two methods can be used to restore multiple databases in different storage groups. If multiple databases are selected when scheduling the restore, the restoration will restore these databases simultaneously by creating a restore.env file for each restore process. To restore databases one by one, as each database is restored it must be mounted before the next database restoration can be started, otherwise the restore.env file for the second job will erase the previous restore.env information without the first one being done. Microsoft Exchange 2000 on-line documentation and the VERITAS Backup Exec on-line help have detailed information on how to perform such a restoration.

Figure 8 shows the restore time for the 500, 1000 and 2000-user environments as well as for the 100-user restore direct from disk.

[pic] Figure 8. Restore times from tape for 500, 1000 and 2000 users, and from disk for 100 users

The following best practices are recommended for the backup/restore process:

• Always back up the Windows 2000 Registry file.

• Avoid using off-line backup. Do full backups periodically and incremental / differential backups in between.

• Create different databases for different users with different SLA time.

• Every 2000 users should use a separate storage group on a different disk array.

• Double the space required for restoration and disk maintenance.

• Before restoring from tape, make a copy of existing database files.

• Dismount the database for the restoration.

• Always restore the database, and mount the database before restarting the computer.

• Try to restore the database on a server isolated from the production environment and run some tests first. If active directory service is needed, replicate the data to a standalone server for the restoration test.

Section 6

Conclusions

The tests show that Dell’s PowerEdge 6450 server and PowerVault 660F/224F storage running in a Dell SAN 4.0 configuration are very well suited to run Exchange 2000 in an enterprise environment. Exchange 2000 Server takes full advantage of the high availability and scalability delivered by such a configuration. With up to 4TB storage space (soon to 8TB), and much configuration flexibility, the PowerVault 660F/224F makes growing the size of the Exchange database a much easier job than with a direct-attach storage environment. With the right design, configuration and continuous monitoring, Dell servers and storage products can be combined with Microsoft Exchange 2000 to create a robust messaging environment.

Contacts

For questions about this paper or the implementation of Microsoft Exchange Server 2000 with Dell products, please contact a Dell sales representative. For comments and feedback about this paper, please send email to us_technology_showcase@.

Solution Enablement Lab and Showcase

Enterprise Systems Group/Storage Systems Group

Dell Computer Corporation

One Dell Way

Round Rock, Texas USA 78682

+1-(800) WWW-DELL (999-3355)

or +1-(512) 338-4400

us_technology_showcase@



Dell, PowerEdge, and PowerVault are trademarks of Dell Computer Corporation. Microsoft and Windows are registered trademarks of Microsoft Corporation. Intel, Pentium and Pentium III Xeon, are registered trademarks or trademarks of Intel Corporation. Other trademarks and trade names may be used in this document to refer to either the entities claiming the marks and names or their products. Dell disclaims proprietary interest in the marks and names of others.

©Copyright 2001 Dell Computer Corporation. All rights reserved. Reproduction in any manner whatsoever without the express written permission of Dell Computer Corporation is strictly forbidden. For more information, contact Dell. Dell cannot be responsible for errors in typography or photography.

Information in this document is subject to change without notice.

Section 7

Appendix A: Reference Documents

1. Microsoft Exchange Web Site

2. Dell Computer Corp. Online

3. Microsoft Exchange 2000 Server Administrator’s Pocket Consultant, William R. Stanek, Microsoft Press

4. Exchange 2000 Server Black Book, Marcus Goncalves, The Coriolis Group, LLC

5. Exchange 2000 Resource Kit, Microsoft Press

Appendix B

MMB2 Workload Definition

|MMB2 User Parameters |

|Parameter |MMB2 |

|Topology Properties |Initialization |

|Distribution Lists (DLs) |  |Mailbox Setup |

|Use DLs? |Yes |# messages in Inbox |55 |

|# DLs per site |100 |# messages in Deleted Items |1 |

|DL min/avg/max |2 /10 /20 |# of new folders |10 |

|  |  |# of messages in new folders |55 |

|  |  |Calendar Setup |

|  |  |# of appointments |25 |

|  |  |Contact Setup |

|  |  |# of contacts |64 |

|Test Properties |

|Send Mail |Make Appointments |

|# of times per day |7 |New appts per day |4 |

|Recipients per Message |1-5, avg 3 |Appt length min/avg/max |1 /3 /9 |

|Add a Dist List to % msg sent |30 |% recurring appointments |15 |

|Save a copy in sent? |Yes |% all day events |5 |

|Process Inbox |Browse Calendar |

|Read new mail per day |12 |# of times per day |6 |

|Message actions |Journal Applications |

| Reply |20 |Activity # of times per day |3 |

| Reply All |7 |Logoff |

| Forward |10 |# of times per day to log off |3 |

| Delete |100 |Always keep connection? |No |

| Move |30 |Empty Deleted Items? |Yes |

| Copy |0 |Browse Contacts |

|Read Note Delay min/avg/max |1.0/1.0/1.0 |# of times per day |10 |

|Load % of attachments |75 |Create Contact |

|Accept % of meeting requests |70 |# times/day to make new contact |1.4 |

|Browse Mail |Test/Logon |

|Browse mail per day |15 |Logon immediately at the very beginning of the test? |Yes |

|Free/Busy |  |Log off at the end of each simulated day? |Yes |

|Update schedule times per day |4 |Empty Deleted Items folder on logoff? |Yes |

|Update Free/Busy Information? |No |Test Report approx. message traffic, per user, per day |

|Schedule Size (kb) min/max/avg |5/40/22 |Total Received |161.9 |

|Request Meetings |  |Reply |20.56 |

|Make new meetings per day |2 |Reply All |6.48 |

|Meeting Length (hrs) min/avg/max |1 /2 /7 |Forward |10.08 |

|Attendees min/avg/max |1/ 5 / 40 |Total Submitted |44.12 |

|Add a DL % of the time |20 |Average # of recipients per message (all msgs) |3.67 |

-----------------------

Average Transfer Size

Average

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download