Transcript
Protecting Hitachi Adaptable Modular Storage 2000 Family and Exchange 2007 Environments with Continuous Replication Solution Guide By Patricia Brailey
April 2009
Summary E-mail is a critical application for organizations of all sizes, which can create a significant challenge for administrators tasked with ensuring these systems are highly available and maintain the ability to resume operations efficiently after planned or unplanned outages. Microsoft® added continuous replication to its Exchange 2007 Server product in an effort to address these and other operational issues related to maintaining a highly-available, enterprise messaging system. Deploying continuous replication on Hitachi’s Adaptable Modular Storage 2000 family storage systems ensures maximum availability, delivers easy management and scalability and provides a centralized storage platform from which technologies such as server virtualization can be fully leveraged — whether implemented now or in the future. Continuous replication, which includes local continuous replication (LCR), cluster continuous replication (CCR) and standby continuous replication (SCR), provides a mechanism for administrators to manage planned outages and guard against various events that can trigger service disruptions in Exchange 2007 environments. Although the three types of continuous replication are closely related, they are implemented individually and in combination to address different availability and recovery scenarios. This white paper describes these scenarios and provides Hitachi Data Systems’ guidance and recommendations to Exchange and storage administrators who are evaluating or planning Exchange 2007 continuous replication deployments.
Contributors The information included in this document represents the expertise, feedback and suggestions of a number of skilled practitioners. The author recognizes and sincerely thanks the following contributors and reviewers of this document: • Mark Adams, Product Marketing • Rick Andersen, SCSSI — Solutions Engineering • Eduardo Freitas, SCSSI — Solutions Engineering • Elizabeth Graul, Application Solutions • Larry Meese, Application Solutions • Lisa Pampuch, Application Solutions
Table of Contents Continuous Replication Overview ...................................................................................................................................... 2 Local Continuous Replication................................................................................................................................... 2 Cluster Continuous Replication ................................................................................................................................ 3 Standby Continuous Replication .............................................................................................................................. 4 Ideal Choice for a Demanding Application......................................................................................................................... 5 Improved Responsiveness ....................................................................................................................................... 6 Improved Availability ................................................................................................................................................ 6 Planning for Continuous Replication ................................................................................................................................. 7 Changes in Exchange 2007 Service Pack 1 ............................................................................................................ 7 Scalability and Availability on the 2000 Family......................................................................................................... 8 Exchange Infrastructure Dependencies ................................................................................................................... 8 Storage Performance and Capacity Considerations ................................................................................................ 9 Tested Deployment .............................................................................................................................................................. 9 Hardware.................................................................................................................................................................. 9 Software ................................................................................................................................................................. 10 RAID Group and LU Configuration......................................................................................................................... 11 Deploying Continuous Replication ................................................................................................................................... 12 Best Practices for Storage Deployment ................................................................................................................. 12 Managing and Monitoring Continuous Replication......................................................................................................... 15 Exchange Management Shell Cmdlets .................................................................................................................. 15 Clustered Mailbox Servers ..................................................................................................................................... 16 Hitachi Storage Management Tools ....................................................................................................................... 17 Monitoring Performance ......................................................................................................................................... 17 Conclusion.......................................................................................................................................................................... 18 Appendix A – Additional References................................................................................................................................ 19
Protecting Hitachi Adaptable Modular Storage 2000 Family and Exchange 2007 Environments with Continuous Replication Solution Guide By Patricia Brailey E-mail is a critical application for organizations of all sizes, which can create a significant challenge for administrators tasked with ensuring these systems are highly available and maintain the ability to resume operations efficiently after planned or unplanned outages. Microsoft® added continuous replication to its Exchange 2007 Server product in an effort to address these and other operational issues. Deploying continuous replication on Hitachi’s Adaptable Modular Storage 2000 family storage systems ensures maximum availability, delivers easy management and scalability and provides a centralized storage platform from which technologies such as server virtualization can be fully leveraged — whether implemented now or in the future. Continuous replication, which includes local continuous replication (LCR), cluster continuous replication (CCR) and standby continuous replication (SCR), provides a mechanism for administrators to manage planned outages and guard against various events that can trigger service disruptions in Exchange 2007 environments. Although the three types of continuous replication are closely related, they are implemented individually and in combination to address different availability and recovery scenarios. This white paper describes these continuous replication scenarios and provides Hitachi Data Systems’ guidance and recommendations to Exchange and storage administrators who are evaluating or planning Exchange 2007 continuous replication deployments on the Hitachi Adaptable Modular Storage 2000 family. It provides best practice recommendations to ensure a smooth deployment of continuous replication and offers an overview of the process of enabling and configuring continuous replication technology in Exchange environments that use Hitachi Adaptable Modular Storage 2000 systems. This white paper is written for the following readers: • Customers who are in the early stages of adopting Exchange 2007 continuous replication technology and
are evaluating the storage infrastructures to support the deployment • Existing Hitachi Adaptable Modular Storage customers who are considering deploying continuous replication
technology in their Exchange 2007 environments • Existing Hitachi Adaptable Modular Storage customers who are planning to transition or migrate to a new
Exchange 2007 environment and are evaluating high availability and protection technologies • Hitachi Data Systems partners and consultants who are responsible for deploying Exchange 2007
continuous replication on the Hitachi Adaptable Modular Storage 2000 family This paper is written for Exchange 2007 administrators with a solid working knowledge of Exchange 2007 and its associated tools, a firm working knowledge of storage and its relationship to Exchange 2007 and a basic understanding of continuous replication. The paper focuses on the mailbox role within Exchange 2007 and is not intended to be a step-by-step guide for deploying continuous replication. Instead, it documents best practice recommendations, outlines the
1
considerations and identifies sources for additional information required to successfully deploy continuous replication in an Exchange 2007 environment on the 2000 family. The deployment tested for this white paper used two Hitachi Adaptable Modular Storage 2300 storage systems with a Brocade 48000 switch as the Storage Area Network (SAN) backbone, along with two Emulex LightPulse LPe111-H host bus adapters (HBAs) in each server housing the Exchange Mailbox role configured to support 1,000 mailboxes. The following software was used in the test environment: • Microsoft Windows Server 2008 SP1 • Microsoft Exchange Server 2007 SP1 • Microsoft Exchange Load Generator v08.02.0045.000 • Hitachi Storage Navigator Modular 2 v5.02 • Hitachi Dynamic Link Manager v6.0.0-01
For more information about the test environment, see the “Tested Deployment” section of this paper.
Continuous Replication Overview LCR, CCR and SCR use asynchronous log shipping and replay technology to maintain a secondary, or passive, copy of the Exchange databases and logs. LCR and CCR are part of the release to market (RTM) version of Exchange 2007, and SCR was added in Service Pack 1 as a disaster recovery solution.
Local Continuous Replication With LCR, the active and passive LUs are presented to a single mailbox server and are configured at the storage group level. The failover process is manual, meaning that the administrator must dismount the databases and run the Restore-StorageGroupCopy cmdlet to activate the passive copies. LCR is disabled at this point, and can only be enabled after the active copies are restored. The LUs for the active and passive copies originate from a single 2000 family system. LCR can be an acceptable alternative to other recovery solutions for environments needing fast recovery from disk failure or physical corruptions of the mailbox database. LCR can reduce recovery time from local, data-level disasters, can reduce the number of full backups needed, and can enable the off-loading of Volume Shadow Copy Service (VSS) backups from the active copy to the passive copy when compared to traditional backup methods. LCR can be managed using the Exchange Management Console (EMC) or with cmdlets in the Exchange Management Shell (EMS), which are described in more detail in the “Planning for Continuous Replication” section of this paper. Figure 1 illustrates an example LCR scenario.
2
Figure 1. Example Local Continuous Replicaiton Scenario
Cluster Continuous Replication CCR integrates asynchronous log shipping and replay capabilities with Windows failover cluster technology. With CCR, two sets of LUs reside on either the same 2000 family storage system or on separate 2000 family storage systems. As in LCR, the two sets of LUs are called active and passive copies. The active and passive copies are presented to two servers, the active node and the passive node, that are set up as one Exchange mailbox server in a failover cluster. CCR maintains the second copy of data with minimal negative effect on performance by using the passive node to copy and replay the logs. When the logs arrive at the passive node, a checksum is validated and then replayed into the copy of the database that is stored on the passive node. The passive copy is used if the active mailbox server becomes unavailable or if the mailbox database fails or becomes corrupt. Like LCR, CCR reduces the number of full backups needed and supports VSS back-ups on the passive node rather than the active node. In addition to providing automatic failover for when unplanned outages occur, CCR also provides the ability to switch to the passive node for scheduled outages such as server maintenance. CCR can be managed using either the EMC or the EMS. Figure 2 illustrates an example CCR scenario.
3
Figure 2. Example Cluster Continuous Replication Scenario
Standby Continuous Replication SCR builds on CCR to provide the most advanced and flexible data protection and availability continuous replication configurations using native Exchange 2007 capabilities. SCR provides disaster recovery and extends the high availability provided by CCR. Like LCR and CCR, SCR uses asynchronous log shipping and log replay. In this case, continuous replication is used to enable the use of standby recovery servers in the environment. With SCR, active and passive copies are referred to as sources and targets. Unlike LCR and CCR, which are limited to a single copy of a given storage group, SCR supports multiple replication targets per storage group and is completely managed using the EMS. In SCR, an additional set of LUs, the target copies, are presented to the standby server, which can be either a stand-alone mailbox server or a standby cluster. The process for bringing an SCR target online is called activation and is a manual process similar to the process used for LCR. The ReplayLagTime parameter that delays log replay is unique to SCR. This setting is enabled using the Enable-StorageGroupCopy cmdlet and by specifying the days, hours, minutes and seconds of the parameter ReplayLagTime. By default the parameter is set to 24 hours, but the administrator has the ability to increase or decrease the delay. The following example illustrates how to configure SCR for the storage group SG1 to the standby machine DL385-3 for a replay lag time of 15 minutes. Enable-StorageGroupCopy -Identity SG1 -StandbyMachine DL385-3 -ReplayLagTime 0.0:15:0 In other words, the replaying of the logs to the standby machine DL-385 lags behind the active copy of storage group SG1 by 15 minutes. For more information about this cmdlet, see the Microsoft TechNet article EnableStorageGroupCopy. Due to the asynchronous nature of continuous replication, if an unscheduled outage occurs, the target node might have a different amount of data than the source node when the system comes back online. This is called divergence. To prevent divergence, lag time is built into the replay feature to give the administrator a chance to control playing the transferred logs into the SCR target (now active) database. This playback process is also called reseeding. In very large databases, reseeding can be a very time- and resource–intensive process, making it difficult to restore the Exchange environment in a timely manner. Figure 3 illustrates an example CCR scenario with the addition of SCR.
4
Figure 3. Example Cluster Continuous Replication with Stanby Continuous Replication Scenario
Ideal Choice for a Demanding Application While this paper focuses on the 2300, the Hitachi Adaptable Modular Storage 2000 family, which includes the 2100, the 2300 and the 2500, provides a reliable, flexible and cost-effective storage platform for demanding applications like Microsoft Exchange Server. The 2000 family delivers 99.999 percent availability and enterprise-class performance, capacity and functionality at a midrange price. The 2000 family provides a reliable, flexible, scalable and cost-effective modular storage system for Exchange Server. No other midrange storage product has symmetric active-active controllers that provide integrated, automated hardware-based front-to-back-end I/O load balancing. This ensures I/O traffic to back-end disk devices is dynamically managed, balanced and shared equally across both controllers, even if the I/O load to specific logical units (LUs) is skewed. Storage administrators are no longer required to manually define specific affinities between LUs and controllers, simplifying overall administration. In addition, this new controller design is fully integrated with standard host-based multipathing, thereby eliminating mandatory requirements to implement proprietary multipathing software. No other midrange storage product that scales beyond 100TB has a serial attached SCSI (SAS) drive interface. The new point-to-point back-end design virtually eliminates I/O transfer delays and contention associated with Fibre Channel arbitration and provides significantly higher bandwidth and I/O concurrency. It also isolates any component failures that might occur on back-end I/O paths. Exchange Server 2007 benefits from the 64-bit platform, advances in Windows Server 2008 and, more recently, Exchange 2007 Service Pack 1 to improve scalability, I/O performance and enhanced cache utilization. The increased memory address space available to Exchange Server 2007, in some instances, can result in reduced performance demands on the storage infrastructure. A few users are concluding from this that they should return to the use of internal server drives. However, SAN-attached storage is better for the following reasons: • Exchange is still a demanding application. New uses of Exchange and additional demands, such as remote
messaging, virus protection and spam prevention can negate these architectural improvements. • SAN-attached storage is more reliable than an internal storage solution. • Single copy cluster (SCC) solutions are not possible with internal storage.
5
• Internal storage limits scalability. • SAN storage can provide better capacity utilization for Exchange.
Intelligent storage systems like the 2000 family deliver enterprise-class capabilities at reduced prices and provide several benefits and capabilities that internal storage simply cannot deliver to Exchange 2007 environments. Organizations that choose centralized storage systems like the 2000 family over internal storage can realize the following benefits and avoid common pitfalls: • Enhanced reliability, availability and scalability • Increased resource utilization and performance • Reduced operational expenditures (OpEx) and management costs • Decreased capital expenditures (CapEx) through server and storage consolidation • No application specific storage silos • Increased organizational velocity and ability to meet demands of dynamically changing business
requirements • Ability to leverage multiple RAID types to tailor an optimized storage design • Advanced solutions:
– Microsoft Windows Volume Shadow Copy Service (VSS) compliant backup and rapid recovery solutions – Zero data loss stretch clustering – Remote replication over short or long distances • Leveraging of advanced capabilities and technologies:
– Server virtualization and advanced techniques like load migration – Retention and compliance through global archiving Two new features of the Hitachi Adaptable Modular Storage 2000 family are especially applicable to Exchange 2007. Dynamic load balancing within the storage system simplifies management even when faced with constantly changing Exchange workloads. Active-active controllers simplify SAN design and improve availability as well as performance.
Improved Responsiveness The new Hitachi Dynamic Load Balancing Controller architecture maintains optimal Exchange performance under changing conditions. Peak activity can be difficult to predict. Spikes might occur due to shifting usage patterns or be related to special projects such as a new product or service launch. Repetitive procedures including integrity checks or virus scans need to be taken into account. All of these are addressed by the 2000 family Load Balancing controllers, which automatically reassign the storage workload when utilization of the two controllers is imbalanced, eliminating bottlenecks. Rebalancing is transparent to hosts and requires no intervention from the Exchange or storage administrator.
Improved Availability On the 2000 family, Exchange hosts can access databases or log logical units (LUs) from any of the front-end host ports on either of the two controller modules due to the true, symmetric active-active design. The system efficiently and automatically passes I/O to the associated controller for processing, regardless of the port on which the I/O arrives. Support for native MPIO enables simplified SAN design, improves basic availability and can enhance performance under a heavy load from multiple Exchange servers or when it is necessary to share ports with other applications. It is still important to use a SAN design that maintains separate and independent paths from the Exchange server to each storage controller, but storage or Exchange administrators no longer need to be concerned about controller ownership of LUs or about access through preferred paths. For example, planned microcode upgrades are carried out on only one of the two controllers at any given time. Although Exchange might operate with reduced storage processing power during an upgrade, the Exchange 6
servers see no change in I/O paths and do not experience path failover events. All front-end ports remain active to the Exchange hosts and automatically route all I/O to the remaining controller. After the upgrade is complete, the Exchange workload is again balanced between the two controllers. Data flow from the servers through the SAN remains balanced throughout the upgrade.
Planning for Continuous Replication Careful planning ensures a smooth deployment and a scalable Exchange continuous replication solution. Because of important features and improvements, if you’re planning to use CCR, Hitachi Data Systems recommends that you use Exchange Server 2007 SP1 release.
Changes in Exchange 2007 Service Pack 1 The release of Exchange 2007 SP1 brought significant changes to LCR and CCR and introduced SCR. Before the release of Exchange 2007 SP1, only CCR was able to make use of the Hub Transport dumpster feature. This feature allows the continuous replication recovery process to take advantage of the mail delivery queue located on the Hub Transport server. As part of the recovery process, messages are resent from the mail delivery queue while any duplicate messages are deleted. In SP1, LCR is now able to use the transport dumpster feature. The size of the transport dumpster and the time a message stays in the queue must be estimated during the planning process. The two relevant parameters are MaxDumpsterSizePerStorageGroup and MaxDumpsterTime and each can be configured through the EMC or by using the Management Shell. Disk space from the Hitachi Adaptable Modular Storage system can be allocated to the Hub Transport server for the transport dumpster. For more information about the advantages that SAN offers over DAS, see the Storage’s Pivotal Role in Microsoft® Exchange Environments: The Important Benefits of SANs solution profile. Use the following formula to estimate the required disk space: MaxDumptsterSizePerStorageGroup X (the number of storage groups on CCR or LCR-enabled storage groups in this Active Directory site) = Required disk space for the Hub Transport dumpster For example, if 12MB is the MaxDumpsterSizePerStorageGroup and the environment has 100 storage groups, the total required capacity for the transport dumpster is 1.2GB: 12MB X 100 storage groups = 1.2GB total capacity If two Hub Transport servers are servicing those 100 storage groups, divide the 1.2GB across the two servers. The RAID level you choose for the RAID group housing this volume depends on the number of I/Os per second (IOPS) and the amount of capacity needed to service your environment. For more information about calculating storage capacity for the Hub Transport Server, see the Microsoft TechNet article Transport Server Storage Design. In addition to allowing LCR to make use of the transport dumpster, SP1 introduced several enhancements to the EMC for both LCR and CCR. The continuous replication interface allows you to suspend, resume, update and restore the continuous replication copy. EMS cmdlets are also available for all management tasks that can be performed through the console. SP1 also enhances the monitoring capabilities available by improving the Get-StorageGroupCopyStatus cmdlet and by introducing another monitoring cmdlet called Test-ReplicationHealth. For more information, see the “Monitoring and Managing Continuous Replication” section in this paper and the Microsoft TechNet article High Availability Cmdlets. SP1 also features performance improvements. A change in the way the database cache behaves during log replay activity greatly reduces the amount of I/O that occurs on the passive copies. The database cache now remains persistent from one log replay activity to the next instead of creating a new database cache during each replay.
7
Scalability and Availability on the 2000 Family The Hitachi Adaptable Modular Storage 2000 family offers much in the way of scalability and availability for your continuous replication environment. Additional storage can be easily provisioned and centrally managed, and the components design eliminates single points of failure. Careful planning before deployment allows for easy growth and recovery, while maintaining the highest availability. Consider the following when planning your Exchange continuous replication environment: • Place database and log data on separate LUs protected by a RAID configuration. Use RAID-1+0 for
databases and RAID-1 for logs and system files. Separating database and log workloads ensures recovery in case of database corruption. • Place passive copies on separate LUs from the active copies. Placing active and passive copies on separate
LUs is a requirement for recovery from failure beyond database corruption. If the active copies fail in some way and the passive copies are located on the same LUs, it is likely the passive copies failed as well. • Make sure the performance characteristics of the underlying disks are equal for active and passive copies.
Similar performance characteristics for active and passive copies are needed in case of failover. The LUs housing the passive copies must be able to handle the load as if they were the LUs of the active copies. • When planning for SCR, consider that the source can have multiple targets and each target can have
multiple source servers. You might want to plan for a stand-by environment in a geographically dispersed data center, or simply in an adjacent rack. • The location of storage groups and databases must be identical on all CCR cluster nodes, and on SCR
source and target servers. Consider using the same drive letter scheme on each server, and name storage groups and databases in a logical and easy-to-remember way.
Exchange Infrastructure Dependencies Data center infrastructure components such as networking devices and Active Directory servers are critical to a successful Exchange deployment. Without a robust data center infrastructure, Exchange user experiences and service levels can degrade. In a worst-case scenario, the entire system can become unavailable. Plan the infrastructure to support Exchange continuous replication, whether you have a small LCR environment or maintain three data centers using CCR and SCR. Follow Microsoft’s guidelines regarding the number of Active Directory, Global Catalog and Domain Name Service (DNS) servers to use in your continuous replication environment. DNS must be running in a CCR environment due to the presence of a failover cluster. In both CCR and SCR environments, servers must be part of the same Active Directory domain, although the nodes can be located in different Active Directory sites. For more information about server roles, see the Microsoft TechNet article Planning Server Role Ratios. Windows 2008 offers improvements over Windows 2003 in terms of networking and clustering, especially the ability to allow cluster nodes to reside on different subnets. As a best practice, use a two-node Windows 2008 failover cluster using the Node and File Share Majority quorum as the cluster configuration for CCR. The file share quorum that acts as the tie-breaker for the cluster can reside anywhere in the domain, but a best practice is to place it on one of the Hub Transport servers in the Exchange environment so that an Exchange administrator can access it without any special privileges. The ability to allow nodes to reside on more than one subnet allows you to use remote data centers as failover sites. Remote data centers present challenges, however, such as the need for adequate infrastructure and bandwidth at both sites. The networking devices that are in place must be able to handle gigabit Ethernet speeds so that tasks like database seeding can be completed in a timely manner. Conduct a cost-benefit analysis to determine whether using a remote data center for disaster recovery is feasible for your IT organization.
8
Storage Performance and Capacity Considerations Initially size your Exchange environment using the guidelines outlined in the Planning for Microsoft® Exchange Server 2007 Deployments on the Hitachi Adaptable Modular Storage 2000 Family white paper. Another useful tool is the Mailbox Server Role Storage Requirements Calculator. Download the calculator from the files page of the Microsoft Exchange Team blog, which also has more information about the calculator. To support the active copies’ performance and capacity requirements, deploy an additional, identical set of RAID groups and LUs to serve as the passive copies in LCR and CCR. To include SCR, an additional, identical set of database and log LUs (or more depending on the number of targets) are needed. In addition, keep these considerations in mind: • Configure a single database per Exchange storage group. This is a requirement for all three types of
continuous replication. • Consider recovery beyond activation of the passive copy. For instance, bigger databases take longer to
recover from tape • After failing over to a passive copy, a new passive copy must be created to return to a protected state. The
process of creating the second copy is called seeding. The seeding process can take a significant amount of time with larger databases. To optimize recovery scenarios, Microsoft recommends a maximum size of 200GB for databases using continuous replication. This is a good rule of thumb, but it might be possible to increase this size depending on the secondary protection solution deployed in your environment. The IT policies governing recovery point objectives, recovery time objectives and tolerance level for data loss shape your continuous replication environment and your entire disaster recovery scheme.
Tested Deployment The following sections describe the configuration used for building and validating the LCR, CCR and SCR scenarios documented in this white paper.
Hardware To support all three continuous replication types, two Adaptable Modular Storage 2300 storage systems were used. This was necessary to simulate multiple data centers and to provide site resiliency scenarios. A Brocade 48000 director was used as the Storage Area Network (SAN) backbone, and two Emulex LightPulse LPe111-H host bus adapters (HBAs) were used in each server housing the Exchange Mailbox role. Table 1 lists server specifications. Table 1. Continuous Replication Testing Server Specifications Number of Servers
Server Make and Model
Role
Memory and Processor
3
HP DL385
Mailbox servers
16GB memory, 2 x dualcore AMD processors
2
HP DL385
LoadGen clients
8GB memory, 2 x dual-core AMD processors
1
HP DL385
Active Directory server, DNS
8GB memory, 2 x dual-core AMD processors
1
HPDL385
CAS and Hub Transport
8GB memory, 2 x dual-core AMD processors
Figure 4 illustrates the test environment topology.
9
Figure 4. Test Environment Topology
Software The following software was used in the test environment: • Microsoft Windows Server 2008 SP1 • Microsoft Exchange Server 2007 SP1 • Microsoft Exchange Load Generator v08.02.0045.000 • Hitachi Storage Navigator Modular 2 v5.02 • Hitachi Dynamic Link Manager v6.0.0-01
LoadGen was used to simulate mail flow and in turn, the movement of transaction logs from the active copy to the passive copy. Table 2 lists the parameters used to set up the LoadGen simulation for all scenarios. Table 2. Continuous Replication LoadGen Test Parameters Number of Storage Groups
5
Number of Databases per Storage Group
1
Number of Users per Database
200
Outlook Profile
Outlook 2007 Cached
User Profile
Very Heavy
10
RAID Group and LU Configuration The base configuration used for the active or source copies in the continuous replication test environment used five storage groups with one database each and one log file each. To keep the configuration simple and to comply with Hitachi Data Systems best practices, one LU was created using the maximum capacity from each RAID group. Table 3 outlines the base storage configuration. Table 3. Detailed Storage Configuration RAID Group
LUN
Size (GB)
RAID Level
RAID Type
Disk Spec
Description
1
1
265
RAID 1+0
2+2
146GB 15K
Storage Group 1
2
2
265
RAID 1+0
2+2
146GB 15K
Storage Group 2
3
3
265
RAID 1+0
2+2
146GB 15K
Storage Group 3
4
4
265
RAID 1+0
2+2
146GB 15K
Storage Group 4
5
5
265
RAID 1+0
2+2
146GB 15K
Storage Group 5
41
41
132
RAID 1
1+1
146GB 15K
SG 1 Log
42
42
132
RAID 1
1+1
146GB 15K
SG 2 Log
43
43
132
RAID 1
1+1
146GB 15K
SG 3 Log
44
44
132
RAID 1
1+1
146GB 15K
SG 4 Log
45
45
132
RAID 1
1+1
146GB 15K
SG5 Log
See Figure 5 for an illustration of the disk configuration for the active copies. Figure 5. Disk configuration for the active copies.
To simulate the passive copies of the LCR environment, ten additional RAID groups and LUs were created on the primary 2300 storage system using the same configuration as the active copies. For CCR, in addition to the configuration used for the active copies, ten RAID groups and LUs with the same configuration were created on the secondary 2300 for the passive copies. To create the CCR with SCR scenario a third set of ten RAID
11
groups and LUs were created on the secondary 2300 for the target copies. The CCR with SCR scenario used a total of 90 disks.
Deploying Continuous Replication To deploy Exchange 2007 with continuous replication on a 2000 family storage system, perform the following high-level tasks. These are general tasks that need to be completed for a successful deployment. Each item involves many detailed steps. Your checklist might vary based on your environment. 1. Prepare servers for Exchange 2007 installation. For example, install Exchange prerequisites, Hitachi-supported HBA drivers and operating system updates, and ensure that the domain is configured properly. For a list of currently supported HBAs and drivers, see the “Interoperability Information” section of the Hitachi Adaptable Modular Storage 2000 page of the Hitachi Data Systems Web site. 2. Configure the RAID groups, LUs and host security groups on the 2000 family storage system for both the active and passive copies, and the SCR target copies if necessary. 3. Configure the storage for the Hub Transport dumpster. 4. Install Hitachi Dynamic Link Manager software or MPIO on the Exchange servers, ensuring that at least two paths are configured from each server to the storage system. 5. Create Windows partitions for the database files and log files. 6. Install Exchange and configure the storage groups, databases and Hub Transport dumpster. 7. Enable LCR or CCR as part of the configuration of the storage groups. 8. If using SCR, ensure that the Mailbox server role is installed on the standby Exchange server. 9. If using SCR, run the Enable-StorageGroupCopy command to enable SCR on the standby Exchange server. 10. Validate the deployed solution with tools such as Microsoft Exchange Server JetStress and the Exchange Best Practice Analyzer. For more information about LCR, CCR and SCR see the Microsoft TechNet article High Availability. For more information about configuring Hitachi Adaptable Modular Storage 2000 family storage systems and Hitachi Dynamic Link Manager software, see the Hitachi Dynamic Link Manager for Windows® Systems User's Guide, which is available to registered customers on the Hitachi Data Systems support portal, and the Hitachi Storage Navigator Modular 2 software’s online help.
Best Practices for Storage Deployment Follow Hitachi Data System’s recommendations for deploying a continuous replication environment on a 2000 family storage system to ensure successful deployment.
Storage Configuration Before installing Exchange, configure all storage, connect it to the planned Exchange servers and create the partitions for the database and log files. Some backup solutions require that the partitions to be backed up be referenced using drive letters. Because it is possible to have more than 13 storage groups on a server, create a few small volumes to use as partitions for mount points. For example, configure two 1GB basic partitions (M: and P:). Create mount points under M: for the Exchange mailboxes, and mount points under P: for the logs. See Figure 6 for an example using three storage group volumes and three log volumes.
12
Figure 6. Configuring Small Volumes to use as Mount Points
If you are deploying CCR and SCR, use the same drive letter and mount point configuration on all nodes. Hitachi Storage Navigator Modular 2 software is part of the Hitachi Basic Operating System software package. It monitors and manages Hitachi modular storage systems, including the Adaptable Modular Storage 2000 family, through either a GUI or command-line interface. Use Storage Navigator Modular 2 software to create the RAID groups, LUs and host storage domains (HSDs), which are sometimes called host groups. Use RAID-1+0 for Exchange database volumes and RAID-1 for log volumes. Create a host storage domain or host group for each Exchange server world wide name (WWN). Figure 7 is a screen shot from Hitachi Device Manager software showing two LDEVs (or LUs) that are assigned to two host storage domains that contain one server WWN each and one port each on the storage system. Figure 7. Hitachi Device Manager Software Screen Shot
You can use Hitachi Device Manager software to configure host storage domains as well. Hitachi Device Manager software provides centralized management of all Hitachi storage systems, including the 2000 family. Device Manager software can link to Storage Navigator Modular 2 software and it has the ability to provision using storage pools, manage replication between storage systems and logically group resources for more efficient management.
13
Install Hitachi Dynamic Link Manager software on all Exchange servers that will host volumes from the 2000 family storage system. Hitachi Dynamic Link Manager software includes capabilities such as path failover and failback and automatic load balancing to provide higher data availability and accessibility. Configure at least two paths to each server with one path to each storage system controller for high availability. On the Fiber Channel switch, zone each Exchange server WWN to one port only on the 2000 family storage system. If possible, have one path per server connected to one switch and the second path connected to a second switch for high availability. Figure 8 shows mailbox servers in a CCR topology set up for high availability. Figure 8. Continuous Cluster Replication Topology
Alternatively, the MPIO feature in Windows 2008 can be installed on the Exchange server. It provides the same multipath functionality as Dynamic Link Manager software, although the load-balancing algorithms are different. No additional configuration beyond creating multiple paths on the 2000 family storage system is necessary to use either MPIO or Dynamic Link Manager software.
Deployment Tools Microsoft offers several tools to help you through the Exchange deployment process. These tools are either available as a free download from Microsoft or are part of the Exchange software package: • Microsoft Exchange Server Jetstress tool — Use to validate the planned storage configuration for
adequate performance and capacity prior to going live. • Validate a Configuration wizard — Evaluates the Windows 2008 failover cluster. Run it before CCR is
deployed. It generates a report listing any errors or warnings. Because CCR uses a two-node cluster with Node and File Share Majority, storage does not need to be presented at the time of the creation of the cluster. Because of this, the validation wizard reports errors regarding missing storage.
14
• Microsoft Exchange Best Practices Analyzer tool — Reviews an Exchange environment and generates a
report listing any errors. As with a standalone Exchange 2007 environment, run the Exchange Best Practices Analyzer, which can be found in the Exchange Toolbox, after Exchange is installed. • Microsoft Exchange Load Generator (LoadGen) tool — A simulation tool to measure the effect of MAPI
clients on Exchange servers. LoadGen allows you to test how a server running Exchange responds to e-mail loads in a full Exchange environment.
Managing and Monitoring Continuous Replication Exchange Server 2007 SP1 includes several tools to help manage and monitor your continuous replication environment.
Exchange Management Shell Cmdlets The Get-StorageGroupCopyStatus cmdlet provides status information for each storage group that uses continuous replication. For example, it reports the last log replayed and generated, the copy queue and replay queue length, and dumpster statistics. It also reports status of the clustered mailbox server (CMS). In SP1, additional replication states are reported including service down, initializing and synchronizing. Prior to the release of SP1,the Get-StorageGroupCopyStatus cmdlet reported the same condition as failed. An alternative to using Microsoft Operations Manager (MOM) to monitor your Exchange 2007 environment is to create a script that runs Get-StorageGroupCopyStatus on a regular basis. Keep in mind that servers with many storage groups have lots of information to report, so run your commands piped to fl (format list) or ft (format table) to get a well-organized view: Get-StorageGroupCopyStatus | fl Figure 9 is a screenshot of the output from the Get-StorageGroupCopyStatus cmdlet. Figure 9. Get-StorageGroupCopyStatus cmdlet Output
15
Test-ReplicationHealth is an additional cmdlet designed to proactively monitor continuous replication and provide information to MOM. The cmdlet runs a series of comprehensive tests on the continuous replication system, checking all components including the replication state, cluster services and queue lengths. The Test-ReplicationHealth cmdlet includes a parameter called MonitoringContext and when it is set to $True the results include monitoring events and performance counters in addition to the service information. Figure 10 is a screenshot of the output for Test-ReplicationHealth cmdlet using the MonitoringContext parameter. Figure 10. Test-ReplicationHealth cmdlet Output
Most of the management tasks for LCR and CCR can be performed using the EMC. The EMS is also available to use for all continuous replication tasks. For SCR, you can only use the EMS to perform management tasks. To enable a storage group for SCR you must run one of these commands: New-StorageGroup Enable-StorageGroupCopy SP-1 includes new parameters for these cmdlets: • StandbyMachine • ReplayLagTime • TruncationLagTime • SeedingPostoned
Clustered Mailbox Servers With CCR, you must manage a clustered mailbox server. During maintenance or other scheduled outages, you must stop, start and move your CMS to another node. Use the following Powershell commands to manage your failover cluster. •
Stop-ClusteredMailboxServer
•
Start-ClusteredMailboxServer
•
Move-ClusteredMailboxServer
Always perform maintenance on the passive node of the cluster. If maintenance needs to be performed on the active node, move the CMS to the other node so the active node becomes the passive node.
16
To determine which node in a CCR environment is hosting the CMS, use the Get-ClusteredMailboxServerStatus cmdlet. As best practice, run this cmdlet before shutting down or restarting any node in the cluster.
Hitachi Storage Management Tools The Adaptable Modular Storage 2000 family system automatically checks for errors on hard disks and other components of the storage system such as the controllers, disk trays and power supplies. Any errors are reported in management tools such as Hitachi Storage Navigator Modular 2 and Hitachi Device Manager software. Storage Navigator and Device Manager software also report events such as LU formats and microprogram updates, and events related to Hitachi replication technologies. Use Storage Navigator and Device Manager software to monitor the 2000 family storage system by enabling email notifications or regularly checking the graphical user interface. Figure 11 shows the Alerts and Events page in Storage Navigator software. Figure 11. Alerts and Events in Storage Navigator Software
Monitoring Performance Exchange continuous replication performance can be monitored a few different ways. You can use Windows Performance Monitor, the Performance Monitor feature in Storage Navigator software, or use Hitachi Tuning Manager software, which provides an end-to-end view of the entire data path from application to physical disks on the storage system. 17
Windows Performance Monitor Open Windows Performance Monitor from the EMC Toolbox to view Exchange performance counters from the server perspective. For a list of counters related to the Exchange Replication service, see the Microsoft TechNet article Monitoring Continuous Replication. These counters enable you to individually monitor the performance and health of each storage group. These are also the counters that are displayed by the Get-StorageGroupCopyStatus cmdlet.
Hitachi Storage Navigator Modular Software Storage Navigator software allow you to monitor performance from the storage perspective. Hitachi Performance Monitor feature is part of the Storage Navigator software package. It acquires information on the performance of RAID groups, logical units and other elements of the storage system while tracking the utilization rates of resources such as hard disk drives and processors. Information is displayed with line graphs in the Performance Monitor windows or saved in .csv files that can later be analyzed by the user.
Hitachi Tuning Manager Software Hitachi Tuning Manager software enables you to proactively monitor, manage and plan the performance and capacity for the Hitachi modular storage that is attached to your Exchange mailbox servers. Hitachi Tuning Manager software consolidates statistical performance data from the entire storage path. It collects performance and capacity data from the operating system, Exchange databases or storage groups, switch ports, storage ports on the storage system, RAID groups and LUs where Exchange files are located and provides the administrator a complete performance picture. It provides historical, current and forecast views of these metrics. For more information about Hitachi Tuning Manager software, see the Hitachi Data Systems support portal.
Conclusion Demand for 24/7 access to e-mail systems and requirements for efficient resumption of service after planned and unplanned outages create a challenge for storage and Exchange administrators. Continuous replication technology, deployed along with Hitachi’s Adaptable Modular Storage 2000 family storage systems, ensures maximum uptime and timely data restoration. This solution also enables administrators to easily manage and scale their environments and to take advantage of technologies such as server virtualization, whether implemented now or in the future. By leveraging the benefits of continuous replication and the features of the 2000 family storage systems and Hitachi storage management software, organizations can achieve these important business goals.
18
Appendix A – Additional References The following books were used as reference for this guide: •
Bijaoui, Pierre, and Juergen Hasslauer. Designing Storage for Microsoft Exchange 2007 SP1. Burlington, MA: Elsevier, 2008.
•
Redmond, Tony. Microsoft Exchange Server 2007 with SP1: Tony Redmond’s Guide to Successful Implementation. Burlington, MA: Elsevier, 2008.
19
Corporate Headquarters 750 Central Expressway, Santa Clara, California 95050-2627 USA Contact Information: + 1 408 970 1000 www.hds.com /
[email protected] Asia Pacific and Americas 750 Central Expressway, Santa Clara, California 95050-2627 USA Contact Information: + 1 408 970 1000 www.hds.com /
[email protected] Europe Headquarters Sefton Park, Stoke Poges, Buckinghamshire SL2 4HD United Kingdom Contact Information: + 44 (0) 1753 618000 www.hds.com /
[email protected] Hitachi is a registered trademark of Hitachi, Ltd. in the United States and others countries. Hitachi Data Systems is a registered trademark and service mark of Hitachi, Ltd. in the United States and other countries. All other trademarks, service marks and company names mentioned in this document are properties of their respective owners. Notice: This document is for information purposes only, and does not set forth any warranty, expressed or implied, concerning any equipment or service offered or to be offered by Hitachi Data Systems. This document describes some capabilities that are conditioned on a maintenance contract with Hitachi Data Systems being in effect, and that may be configuration dependent, and features that may not be currently available. Contact your local Hitachi Data Systems sales office for information on feature and product availability. © Hitachi Data Systems Corporation 2009. All Rights Reserved AS-006-00 April 2009
