EMC Symmetrix VMAX and Microsoft Exchange Server · PDF fileEMC Symmetrix VMAX and Microsoft...

EMC Symmetrix VMAX and Microsoft Exchange Server

Applied Technology

Abstract

This white paper provides an overview of how Microsoft Exchange can be deployed on the EMC® Symmetrix® VMAX™ array. The Symmetrix VMAX hardware architecture, connectivity options, layout considerations, and new features within Enginuity™ are discussed as they relate to implementing Microsoft Exchange.

May 2010

Copyright © 2009, 2010 EMC Corporation. All rights reserved.

EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice.

THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.

For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com

All other trademarks used herein are the property of their respective owners.

Part Number h6205.1

EMC Symmetrix VMAX and Microsoft Exchange Server Applied Technology 2

Table of Contents Executive summary ............................................................................................4 Introduction.........................................................................................................4

Audience ...................................................................................................................................... 4 Symmetrix VMAX system...................................................................................4 Storage design....................................................................................................7

Enterprise Flash drives ................................................................................................................ 9 Virtual Provisioning .................................................................................................................... 10

Virtual Provisioning enhancements........................................................................................ 10 Large volume support ................................................................................................................ 10

Connectivity recommendations.......................................................................11 Auto-provisioning Groups ...............................................................................13

Auto-provisioning Groups example – Exchange Cluster ........................................................... 14 Presenting additional devices................................................................................................. 15

Symmetrix VMAX Enhanced Virtual LUN Technology...................................17 Striped metavolume expansion.......................................................................22

Striped metavolume expansion example................................................................................... 23 Volume management with Symmetrix Integration Utilities ...........................25 Conclusion ........................................................................................................26 References ........................................................................................................26


Executive summary The EMC® Symmetrix® VMAX™ Series with Enginuity™ is a new entry in the Symmetrix family. Built on the strategy of simple, intelligent, modular storage, it incorporates a new scalable Virtual Matrix™ interconnect design that allows the storage array to seamlessly grow from an entry-level configuration into the world’s largest storage system. The Symmetrix VMAX system provides the highest levels of performance and scalability for demanding enterprise storage environments while maintaining support for EMC’s broad portfolio of platform software offerings. Enginuity version 5874 is the new, feature-rich Enginuity release supporting the Symmetrix VMAX arrays. With the release of Enginuity 5874, Symmetrix VMAX systems deliver new software capabilities that improve capacity utilization, ease of use, business continuity, and security.

With advanced levels of data protection and replication, the Symmetrix VMAX Series is at the forefront of enterprise storage area network technology. Additionally, the Symmetrix VMAX array is more efficient, faster, and larger and can transparently optimize service levels without compromising the capability to deliver performance on demand. These capabilities are of great value for large server deployments including Microsoft Exchange.

Introduction This white paper discusses new features introduced with the release of Symmetrix VMAX that are the most relevant to a Microsoft Exchange deployment including Auto-provisioning Groups and Virtual LUN migration technology. The paper also discusses high-level considerations concerning storage layout and connectivity for Exchange servers with the Symmetrix VMAX array.

Audience This white paper is intended for Exchange administrators, storage administrators and architects, customers, and EMC personnel looking to understand implementation of Microsoft Exchange on Symmetrix VMAX with Enginuity version 5874.

Symmetrix VMAX system The Symmetrix VMAX system is an innovative platform built around a scalable Virtual Matrix interconnect design. It incorporates powerful multi-core processors and can seamlessly grow from an entry-level configuration into the world’s largest storage system.

The Symmetrix VMAX provides the highest levels of performance, featuring:

• Support for as few as 48 drives up to 2,400 drives • From one to 10 drive bays • Up to 240 drives per bay • Support for two to 16 directors connected via redundant fabric • Flexible connectivity options: Fibre, FICON, iSCSI, GigE • More host port and SRDF port configurations than Symmetrix DMX-4 • 2x more back-end ports compared to Symmetrix DMX-4 • Approximately 2x more Fibre Channel IOPS performance vs. Symmetrix DMX-4 • Heterogeneous support for mainframe, UNIX, Series i, x86, and virtualized hosts

Along with these features, Symmetrix VMAX supports the drive types listed in Table 1.


Table 1. Drive types supported in the Symmetrix VMAX array

Drive type Rotational latency Capacity SATA 7.2k 1 TB 4 Gb FC 10k 400 GB 4 Gb FC 15k 146 GB, 300 GB, 450

GB 4 Gb Flash (SSD) n/a 200 GB, 400 GB

The Symmetrix VMAX provides the ultimate in scalability, including the ability to incrementally develop back-end performance by adding additional directors and storage bays. At the core of the Symmetrix VMAX is the VMAX Engine. Each VMAX Engine contains two directors and controls eight back-end Fibre Channel loops, which support up to either 240 or 360 drives depending upon configuration. Each engine also provides front-end as well as back-end connectivity. Figure 1 gives a logical depiction of a VMAX Engine.

Figure 1. Symmetrix VMAX Engine A Symmetrix VMAX array is defined by up to eight VMAX Engines, which are integrated into a single system image through their fully redundant Virtual Matrix interfaces. This Virtual Matrix Architecture™ allows for the online addition of VMAX Engines, providing the exceptional scalability for a VMAX array. Figure 2 details the Virtual Matrix Architecture provided by a Symmetrix VMAX array comprised of eight VMAX Engines.


Figure 2. Symmetrix VMAX Virtual Matrix

The Virtual Matrix Architecture ensures that any host connected to any VMAX Engine will be able to connect to the necessary storage, irrespective of which VMAX Engine the storage is connected to. All connectivity between VMAX Engines is fully redundant against single points of failure.

When a VMAX system is configured with all eight highly available VMAX Engines and a full complement of 10 storage bays, a layout as shown in Figure 3 will be created. From the labels provided in and the associated VMAX Engine numbers listed in the system bay, it is possible to see the relationship between VMAX Engine and storage bay connectivity. The VMAX system must grow from the inside out.

Figure 3. Fully configured VMAX with eight VMAX Engines

Capacity and performance upgrades can be performed online with no impact to production applications. In fact, all configuration changes, hardware and software updates, and service procedures are designed to be performed online and nondisruptively. This ensures that customers can consolidate without compromising availability, performance, and functionality, while leveraging true pay-as-you-grow economics for high-growth storage environments.


Along with the aforementioned hardware improvements, additional enhancements and features have been included with Enginuity 5874 for the Symmetrix VMAX system. These features include the following:

• Simpler tiered storage management with Enhanced Virtual LUN Technology • Virtual Provisioning™ enhancements • CConcurrent configuration changes • Support for 512 hypers per drive and large volume support • Simpler management of consolidated and virtual environments with Symmetrix Management Console • Initiator groups and new management integration • Cost and performance-optimized business continuity enhancements including SRDF®/Extended

Distance Protection, faster resynchronization times, support for 250 SRDF groups, and additional SRDF, TimeFinder®, and Open Replicator enhancements

Additional details and information regarding the Symmetrix VMAX Series with Enginuity, including its architecture and new features, can also be found in the “References” section on page 26.

The rest of this white paper will detail the specific VMAX features that most relate to Microsoft Exchange Server environments.

Storage design Sizing and configuring storage for use with Microsoft Exchange Server is a process driven by many variables and factors that vary from organization to organization. One method used in an effort to simplify the sizing and configuring of EMC Symmetrix storage for use with Microsoft Exchange Server is to define a unit of measure or work that meets all of the Exchange Server recommended metrics for satisfactory performance. The idea is similar in nature to using building blocks where a predefined amount of Exchange Server work can be quantified and deployed on a compartmentalized amount of next-generation Symmetrix storage that is known to have a predicted performance result.

In general the size of the building block will be based on the expected Exchange user profile including the expected IOPS per user along with the desired mailbox size for each user. Once this is determined the required disk type, number of drives, and RAID protection can be determined to support the expected workload.

A detailed explanation of the building block approach as well as examples and best practices for sizing storage for Microsoft Exchange can be found in the Microsoft Exchange Server on EMC Symmetrix Storage Systems TechBook. The best practices derived in this document can be applied for Exchange configurations on the Symmetrix VMAX system.

One possible implementation of Microsoft Exchange within a VMAX system is to isolate building blocks into separate octants (separate VMAX Engines) such that certain engines will only contain drives dedicated to the Exchange servers connected to that same node. This configuration delivers predictable performance by isolating the front-end and back-end resources for a particular set of Exchange servers or a particular function, such as TimeFinder operations or resources dedicated for backup to disk.


Figure 4 provides a depiction of separating VMAX Engines (or octants) to service specific hosts or workloads.

Octant B

Octant A

Octant C

Octant D

SATA drivesBackup to

Disk


Disk

Octant C, node 3, dir 5 and 6

15k drives Exchange Server C-D


Octant D, node 6, dir 11 and 12

15k drives Exchange Server E-F


Octant A, node 4, dir 7 and 8

Flash drives Exchange

Servers A-B

Octant B, node 5, dir 9 and 10

Flash drivesExchange

Servers A-B

Figure 4. Symmetrix VMAX with isolated tiers

Predictable performance is available in this configuration because workloads are segregated but the segregation reduces potential performance by restricting the total director resources available to any given workload.

In preference to segregation of resources within the VMAX array, it may prove beneficial to spread the different applications and types of drives throughout the system. Given the potential for variable workloads between Exchange servers, i.e., some Exchange servers may be busier than others at specific points in time, it will be beneficial to allow each host and their respective disks or building block to be spread across as many of the available director resources as possible. Figure 5 shows a simplified example of an array with the intermixing drive speeds and host connectivity across all of the directors in the system. In this configuration, a given number of hosts or drives are not isolated to a single VMAX Engine. All host front-end connections and back-end drives are spread across all available directors in the system. This configuration maximizes the director resources available for any given Exchange server and delivers the highest total performance available to all applications and functions.


Octant B

Octant A

Octant C

Octant D


Servers A-B


Octant C, node 3, dir 5 and 6


Disk


Octant D, node 6, dir 11 and 12



Octant A, node 4, dir 7 and 8

SATA drives Backup to

Disk

Octant B, node 5, dir 9 and 10


Servers A-B

Figure 5. Symmetrix VMAX with distributed tiering

Enterprise Flash drives Like Symmetrix DMX-4, Symmetrix VMAX storage arrays support enterprise Flash drives. VMAX supports both 200 GB and 400 GB Flash drives with a 4 Gb attachment. Flash drives have enabled the creation of a new Tier 0 ultra-performance storage tier, which removes previous performance limitations imposed by magnetic disk drives.

For years, the most demanding enterprise applications have been limited by the performance of magnetic disk media. Tier 1 performance in storage arrays has been constrained by the physical limitations of hard disk drives. Enterprise Flash drives for Tier 0 deliver unprecedented performance and response times, which are benefits well suited for demanding Microsoft Exchange Server configurations.

Enterprise Flash drives dramatically increase performance for latency-sensitive databases like Microsoft Exchange. Enterprise Flash drives, also known as solid state drives (SSD), contain no moving parts, which removes much of the storage latency delay associated with traditional magnetic disk drives. A Symmetrix VMAX with enterprise Flash drives can deliver single-millisecond application response times and up to 30 times more I/O operations per second (IOPS) than traditional Fibre Channel hard disk drives (HDD). Additionally, because there are no mechanical components, Flash drives consume significantly less energy than hard disk drives. When replacing a larger number of HDDs with a lesser number of enterprise Flash drives, energy consumption can be reduced by up to 98 percent for a given IOPS workload.

The high-performance characteristics of enterprise Flash drives eliminate the need for organizations to purchase large numbers of traditional HDDs, while only utilizing a small portion of their capacity to satisfy the IOPS requirements of Exchange databases. The practice of underutilizing a hard disk drive for increased performance is commonly referred to as short-stroking. Enterprise Flash drives can increase Exchange database performance and eliminate the need to short-stroke drives, thus keeping storage footprint and power consumption to a minimum and reducing total cost of ownership (TCO).

For additional information on the use of Enterprise Flash drives with Microsoft Exchange, please see the white paper EMC Symmetrix DMX-4 Enterprise Flash Drives with Microsoft Exchange available on Powerlink®, EMC’s partner- and customer-only extranet.


Virtual Provisioning Virtual Provisioning, generally known in the industry as “thin provisioning,” enables organizations to enhance performance and increase capacity utilization for Exchange Server environments. The Symmetrix VMAX system includes Virtual Provisioning support native to Enginuity version 5874.

Symmetrix thin devices are host accessible devices that can be used in many of the same ways that Symmetrix devices have traditionally been used. Unlike regular host accessible Symmetrix devices, thin devices do not need to have physical storage completely allocated at the time the device is created and presented to a host. The physical storage that is used to supply disk space to thin devices comes from a shared storage pool called a thin pool. The thin pool is comprised of devices called data devices that provide the actual physical storage to support the thin device allocations.

When a write is performed to a part of the thin device for which physical storage has not yet been allocated, the Symmetrix allocates physical storage from the thin pool for that portion of the thin device only. The Symmetrix operating environment, Enginuity, satisfies the requirement by providing a block of storage from the thin pool called a thin device extent. This approach allows for on-demand allocation from the thin pool and reduces the amount of storage that is consumed or otherwise dedicated to an Exchange instance.

The architecture of Virtual Provisioning creates a naturally striped environment where the thin extents are allocated across all volumes in the assigned storage pool. By striping the data across all devices within a thin storage pool, a widely striped environment is created. The larger the storage pool for the allocations, then the greater number of devices that can be leveraged for a given Exchange server instance. It is this wide and evenly balanced striping across a large number of devices in a pool that allows for optimized performance in the environment.

For additional information on the use of Virtual Provisioning with Microsoft Exchange, please see the white paper Implementing Virtual Provisioning on EMC Symmetrix with Microsoft Exchange Server available on Powerlink.

Virtual Provisioning enhancements With the Symmetrix VMAX array in conjunction with Enginuity version 5874, thin pools now can be reduced in size nondisruptively, helping reuse space to improve efficiency. When a data device is disabled, it will first move data elsewhere in the pool by draining any active extents to other, enabled data devices in the thin storage pool. Once the draining is complete, that data device can then be removed from the pool.

In addition to reusing space more efficiently, benefits of this capability include the ability to:

• Adjust the subscription ratio of a thin pool – that is, the total amount of host perceived capacity divided by the underlying total physical capacity

• Adjust the utilization or “percent full” of a thin pool • Remove all data volumes from one or more physical drives, possibly in preparation for removal of

physical drives with a plan to replace them with higher capacity drives Customers can virtually provision all tiers and RAID levels, and support local and remote replication for thin volumes and pools using any RAID type. This includes support for data devices of RAID 1, RAID 5 (3+1), RAID 5 (7+1), RAID 6 (6+2), and RAID 6 (14+2), as well as support for TimeFinder/Clone, TimeFinder/Snap, SRDF/A, SRDF/S, SRDF/DM, Open Replicator, and Open Migrator.

Large volume support Prior to Enginuity 5874, the largest single logical volume that could be created on a Symmetrix was 65,520 cylinders, approximately 59.99 GB. With Enginuity version 5874, a logical volume can be configured up to a maximum capacity of 262,668 cylinders, or approximately 240.48 GB, about four times as large as with Enginuity version 577x. This simplifies storage management and provides additional flexibility by reducing the required number of volumes to meet a given space requirement.


In general, fewer larger logical volumes perform well in a Symmetrix environment; however, to ensure the best possible performance experience, large volumes should be carefully considered in a traditional, fully provisioned environment with Microsoft Exchange. For example, to assign a single large logical volume that is RAID 1 protected would only allow for two physical spindles to support the workload intended for that LUN. Should the RAID protection be RAID 5 7+1, for instance, then this concern is lessened as eight disks would be available to service the workload.

Large volume support provides most value in Virtual Provisioning environments. In these environments, customers may strive to overprovision the thin pool as a means to improve storage utilization. Furthermore, Virtual Provisioning deals with the performance needs by utilizing a striping mechanism across all data devices allocated to the thin pool. Performance limits can be mitigated by the total number of spindles allocated to the thin pool.

The implication of utilizing a smaller number of large volumes extends to features such as Symmetrix Remote Data Facility (SRDF). Using a smaller number of larger volumes, as compared to a larger number of smaller volumes, would limit the synchronous write workload capable of running in parallel to the remote site. Such configurations may create additional latency during concurrent database file writes for example.

With these considerations in mind, it is recommended to use striped metavolumes for Exchange database file LUNs in traditional, full provisioned environments. The number of members in the meta will be dependent on the specific configuration, however, the goal should be to spread the metavolume and subsequently the host workload against the assigned disk group as evenly as possible. For the Exchange log volume, when considering the I/O to that LUN will be serial and sequential, a striped metavolume with a large number of metamembers is not as critical. However, a striped metavolume that meets the required space requirements is still recommended. Should Virtual Provisioning be used in the environment, the wide striping inherent to this technology mitigates the need to use striped metavolumes in most Exchange environments.

Connectivity recommendations It is recommended to configure two host bus adapters (HBA) per Exchange server with the goal of presenting multiple unique paths to the Symmetrix VMAX system. The benefits of multiple paths include high availability from a host, switch, and Symmetrix front-end director perspective, as well as enhanced performance.

From a high-availability perspective, given the possibility for director maintenance, including memory upgrades, each Exchange server should have redundant paths to multiple front-end directors. Each Exchange server should be connected to the even and odd directors within a VMAX Engine, or across directors within multiple VMAX Engines (recommended when multiple engines are available).

For each HBA port at least one Symmetrix front-end port should be configured. It is recommended that each HBA port be configured to two Symmetrix front-end ports. Connectivity to the Symmetrix front-end ports should consist of first connecting unique hosts to port 0 of the front-end directors before connecting additional hosts to port 1 of the same director and processor. This methodology for connectivity ensures all front-end directors and processors are utilized, providing maximum potential performance and load balancing for I/O intensive Exchange operations like database checkpoints.

Figure 6 uses a physical view of a high-availability node to provide a depiction of the aforementioned recommendations.


Figure 6. VMAX Engine connectivity example for Microsoft Exchange

Configurations with multiple paths to storage LUNs will require a path management software solution on the Windows host. The recommended solution for multipathing software is EMC PowerPath®, the industry-leading path management software with benefits including:

• Enhanced path failover and failure recovery logic • Improved I/O throughput based on advanced algorithms such as the Symmetrix Optimization load

balancing and failover “policy” • Ease of management including a Microsoft Management Console (MMC) GUI snap-in and CLI

utilities to control all PowerPath features • Value-added functionality including Migration Enabler, to aid with online data migration, and LUN

encryption utilizing RSA technology • Product maturity with proven reliability over years of development and use in the most demanding

enterprise environments While PowerPath is recommended, an alternative is the use of the Multipath I/O (MPIO) capabilities native to the Windows operations system. The MPIO framework has been available for the Windows operating system for many years; however, it was not until the release of Windows Server 2008 where a generic device specific module (DSM) was provided by Microsoft to manage Fibre Channel devices. For more information regarding the Windows MPIO DSM implementation, please see the “Multipath I/O Overview” at http://technet.microsoft.com/en-us/library/cc725907.aspx.

Should native MPIO be chosen as the method for path management in Windows 2008, it is important to note that the default failover policy for Symmetrix devices is “Fail Over Only.” For performance reasons, especially in an Exchange Server environment, it will be beneficial to modify this default behavior to one of the other options, including but not limited to, “Round-Robin” or “Least Queue Depth.” The load-balance policy can be found under the “MPIO” tab within the “Properties” of each physical disk resource in the Windows Device Manager, as depicted in Figure 7.


http://technet.microsoft.com/en-us/library/cc725907.aspx

Figure 7. MPIO Load Balance Policy

For more regarding how to configure Microsoft’s Native MPIO with Windows Server 2008 and the EMC Symmetrix, please see the EMC Host Connectivity Guide for Windows available on Powerlink.

Auto-provisioning Groups Introduced in Solutions Enabler 7.0, the Auto-provisioning Groups feature provides an easier, faster way to provision storage, reducing labor and risk of user error in Symmetrix VMAX arrays running Enginuity version 5874. The majority of applications running on Symmetrix arrays require a fault-tolerant environment with clustered hosts as well as multiple paths to devices. Auto-provisioning Groups was developed to make storage allocation easier and faster, especially in clustered and virtualized server environments.

Mapping and masking devices in previous versions of Solutions Enabler required a separate command for each initiator/port combination through which devices would be accessed. In Solutions Enabler 7.0, the symaccess command allows the user to create a group of devices (storage group), a group of director ports (port group), and a group of host initiators (initiator group), and associate them in a masking view.

When the masking view is created, the devices are automatically masked. If the devices in the storage group are not mapped to the front-end ports in the port group, they will also be mapped before the operation completes. Once the symaccess command that creates the view completes, the devices are available to the initiators on the storage ports. No further Solutions Enabler operations are required. In simple configurations a masking view, along with an associated storage, port, and initiator group, can be created for a single initiator on a single port with any number of devices using a single symaccess command.


After the masking view is created, any objects (devices, ports, or initiators) added to an existing group automatically become part of the associated masking view. This means that no additional steps are necessary to add additional devices, ports, or initiators to an existing configuration. All necessary operations to make them part of the configuration are handled automatically by Symmetrix Enginuity once the objects are added to the applicable group. This greatly reduces the number of commands required to add additional objects to an existing configuration and allows for easier storage allocation and de-allocation.

Auto-provisioning Groups example – Exchange Cluster The Auto-provisioning Groups functionality provides significant value when storage administrators are building or deploying new Windows Servers to form a Windows Failover Cluster. In the following section we will detail a scenario where a two-node Exchange cluster requires access to a shared number of devices. In addition to the shared number of devices, each Exchange server requires unique gatekeepers independent from the cluster. The general steps that can be followed to accomplish this goal are the following:

Step 1. Create the storage group, which will contain the shared clustered devices. Step 2. Create the port group, which will contain the ports required for each cluster node. Step 3. Create unique initiator groups for each cluster node containing the HBAs for that node Step 4. Create the initiator group to be used within the view for the cluster. Step 5. Create the masking view containing the clustered device storage group, the port group, and

the cluster initiator group. Step 6. Create unique storage groups, which will contain the gatekeeper devices for each node. Step 7. Create unique port groups representing the ports zoned to each cluster node. Step 8. Create the masking view containing the gatekeeper device storage group, port group, and

node-specific initiator group.

1. Create the storage group, which defines the specific Symmetrix devices that will be presented to the cluster.

symaccess create -name Cluster_Devs -type storage devs 39B:3A7 -sid 1194

2. Create the director group, which defines the directors to which the devices are to be mapped, and through which the cluster will be able to access the devices as defined in the storage group.

symaccess create -name Cluster_Ports -type port -dirport 7e:0,7f:0,7g:0,7h:0,10e:0,10f:0,10g:0,10h:0 -sid 1194 Note: In this example while all eight directors are in the same port group, not all ports will be seen by each HBA. Specific HBA to FA connectivity and subsequently device access will ultimately be defined by the zoning in the SAN.

3. Create the host initiator groups, which define the WWNs of the HBAs that are used by each node of

the cluster.

symaccess create -name Node1 -type initiator -wwn 10000000c97b0f00 -sid 1194 symaccess add -name Node1 -type initiator -wwn 10000000c979fe12 -sid 1194 symaccess create -name Node2 -type initiator -wwn 10000000c938af5c –sid 1194 symaccess add -name Node2 -type initiator -wwn 10000000c938af5d -sid 1194

4. Create the cluster initiator group containing the host initiator groups defined in the previous step.

Symaccess create -name Cluster_IGRP -type initiator -sid 1194 –ig Node1 symaccess add –name Cluster_IGRP –type initiator –sid 1194 –ig Node2


Note: Placing groups within other groups (also known as cascading or nesting groups) is only supported with initiator groups. Initiator groups support only a single level of nesting.

5. Define the view that binds the previously defined cluster groups. The creation of the view will cause the Symmetrix to execute mapping and masking operations as necessary to facilitate the process.

symaccess create view -name Cluster_View –sg Cluster_Devs -pg Cluster_Ports -ig Cluster_IGRP -sid 1194 Once the view is created, each node in the cluster will be able to rescan their adapters and subsequently discover the storage as defined by the groups within the view.

6. Create the storage groups, which define the specific gatekeeper devices that will be presented to each

node.

symaccess create -name Node1 -type storage devs 54:57 -sid 1194

symaccess create -name Node2 -type storage devs 60:64 -sid 1194

7. Create the director groups, which define the directors unique to each cluster node.

symaccess create -name Node1 -type port -dirport 7e:0,7g:0,10e:0,10g:0 -sid 1194 symaccess create –name Node2 -type port -dirport 7f:0,7h:0,10f:0,10h:0 -sid 1194

8. Define the views, which bind the previously defined node specific groups. These additional views will allow unique devices to be presented to each cluster node.

symaccess create view –name Node1 –sg Node1 -pg Node1 -ig Node1 -sid 1194 symaccess create view –name Node2 –sg Node2 -pg Node2 -ig Node2 -sid 1194

Presenting additional devices Once the groups are created and the views are defined, presenting additional devices to the cluster, or either node, simply requires adding the devices into the appropriate storage group.

For example, to present a new device to the cluster, add the new device to the Cluster_Devs storage group.

symaccess add dev 3eb -sid 1194 -name Cluster_Devs -type storage

To present a new device just to node one, add the new device to the Node1 storage group.

symaccess add dev 58 -sid 1194 -name Node1 -type storage

When devices are added to storage groups already defined within views, the appropriate mapping and masking operations are executed automatically. The only additional step would be to rescan the host adapters to discover the newly provisioned storage on the Windows server.

This example implementation of the Auto-provisioning Groups functionality may be viewed pictorially in Figure 8.


Figure 8. Auto-provisioning Groups example including nested initiator groups It should be noted that the previous example can also be implemented without the use of cascading (nesting) initiator groups. Instead of having a single cluster view, multiple views could be created utilizing the ClusterDevs storage group in conjunction with the existing node-specific port and initiator groups. Figure 9 gives an example of this alternative method for implementing the previous example.

Using the same syntax for commands as outlined previously, this alternative implementation for Auto-provisioning Groups can be accomplished with the following steps:

Step 1. Create the storage group, which will contain the shared clustered devices. Step 2. Create unique initiator groups for each cluster node (Node1, Node2) containing the HBAs for

that host. Step 3. Create unique port groups, which will contain the ports required for each cluster node (Node1,

Node2). Step 4. Create a masking view containing the clustered device storage group, the port group for

Node1, and the initiator group for Node1. Step 5. Create a masking view containing the clustered device storage group, the port group for

Node2, and the initiator group for Node2. Step 6. Create unique storage groups that will contain the gatekeeper devices for each node Step 7. Create the masking view containing the node-specific gatekeeper device storage group, the

node-specific port group, and the node-specific initiator group.

Figure 9. Alternate implementation of Auto-provisioning Groups

The decision to use a specific method for utilizing initiator groups is ultimately up to the preference of the administrator. For clusters with a smaller number of nodes, the method of creating multiple node-specific cluster views may be the preferred method for the sake of simplicity. For clusters with a large number of


nodes, administrators may prefer to utilize the cascaded initiator group functionality to limit the number of views required in the environment. As demonstrated, Auto-provisioning Groups provide the functionality and flexibility required to help reduce the administrative overhead when presenting storage to Exchange hosts.

Symmetrix VMAX Enhanced Virtual LUN Technology EMC Solutions Enabler Enhanced Virtual LUN Technology enables transparent, nondisruptive data mobility between storage tiers for Symmetrix VMAX volumes. This technology is based on the Symmetrix VMAX system, including a new RAID implementation for Symmetrix known as RAID Virtual Architecture (RVA), and requires Enginuity version 5874. Enhanced Virtual LUN migration provides users the ability to move data tiers within a VMAX system. This new functionality is used to either change RAID protection types, move between physical disk groups, or both. Virtual LUN supports the migration of regular devices and metadevices, and can utilize configured or unconfigured disk space for target locations. Unconfigured disk space is a target location that has no hypervolume assignment, while configured disk space uses existing next-generation Symmetrix system logical volumes that are currently not assigned to a host. In previous Enginuity versions, Symmetrix logical devices supported one RAID protection type per device. Also, some RAID types, RAID 1 and RAID 5, occupied two of the four available mirror positions for a given device.

Enginuity 5784 introduces RVA. With RVA, each local RAID group is abstracted to a single mirror position. Currently, two distinct RAID groups, a primary and a secondary, can be associated with a Symmetrix logical device, though only during a Virtual LUN migration.

Migrations are thus facilitated by the creation and movement of data between these RAID groups. Upon completion of the migration, the original RAID group is deleted and the devices are reformatted.

Because Virtual LUN migrations are performed at the RAID group level, an entire LUN will be migrated from the host perspective. This means data movement will involve all objects assigned to that LUN and associated RAID group(s). For Exchange, this will involve either a log volume or a database volume with one or multiple databases assigned. Exchange Server administrators are able to utilize this functionality in a number of ways, such as to address inadvertent misplacement of data LUNs on underperforming devices. In this condition, a database administrator may identify that certain database files are not performing adequately due to an inappropriate selection of RAID type, or due to placement on physical drives that are suffering from high aggregate workloads. In this case, it is possible to identify devices or free storage areas that may be used to migrate the existing LUN. The migration of the LUN will subsequently migrate the data files that reside on that LUN, while providing continuous access to the data and therefore mitigating any loss of availability for the database. Solutions Enabler provides a command line interface (symmigrate) to define and execute the migration process. In the following example of this migration capability, the migration of a LUN containing the database file for a particular storage group is being undertaken. The source volume is a four-way striped metavolume on RAID 5 devices residing on SATA drives. The target of the migration for this example will be to unconfigured (free) space within a 15k rpm Fibre Channel disk group. Thus, the migration in this instance is between RAID levels and tiers of storage, by moving from SATA drives to 15k rpm Fibre Channel drives.

The database file to be migrated for this example, as depicted in Figure 10, is the database LUN for storage group SG2, which contains a single database file, SG2DB1.edb, on the K drive.


Figure 10. Exchange database to be migrated with Virtual LUN technology In the case where Solutions Enabler is installed on the Exchange server hosting the database, the symrslv command can be used to map the specific mount point, for the partition hosting the data files, to the Symmetrix volume(s) on which it resides. Figure 11 displays the output from the symrslv command, and shows that the Windows partition mounted to k:\ is residing on a metavolume whose head is device 41F within Symmetrix 1194.

Figure 11. symrslv command to map a filesystem to a Symmetrix device To migrate metavolume 41F, the symmigrate operation will be executed by defining an input file that will contain the necessary source devices. The definition of the devices in the file migrate_K.txt is shown in Figure 12.


Figure 12. Text file defining the source device for Virtual LUN migration

In this example, device 41F is the source metavolume comprised of four hypervolumes where 41F is the metavolume head. The subsequent metavolume members do not have to be listed. The target for the migration will be defined within the command line, specifically a target disk group and a target RAID type. In this example the migration will be to disk group 0 and to a RAID 1 configuration. To view disk group information, the symdisk command can be used to determine drive types as well as free space, as depicted in Figure 13.

Figure 13. Viewing disk groups with the symdisk command

To initiate the migration process, the symmigrate command is called, first with the validate parameter, to ensure that the configuration is correct, and then with the establish parameter, to begin the migration. The specific syntax for both commands are as follows:

Command to validate the migration:

symmigrate -name Exchange_SG2 -file c:\migrate_K.txt -tgt_unconfig -sid 94 -tgt_dsk_grp 0 -tgt_raid1 validate –nop

Command to begin the migration:

symmigrate -name Exchange_SG2 -file c:\migrate_K.txt -tgt_unconfig -sid 94 -tgt_dsk_grp 0 -tgt_raid1 establish –nop

Once the LUN migration is initiated, a copy operation begins between the source device (RAID groups) and the target device (or free space) as defined in the command line.

Figure 14 displays a partial output of the symdev show command for the source device 41F as taken during the migration. It is possible to see the nature of the migration in the Mirror Set Type field, where the first mirror position shows that the source device is a RAID 5 configuration, and the secondary mirror is a RAID 1 configuration.


Figure 14. symdev show command during the Virtual LUN migration The session name, Exchange_SG2, as specified in this example can be used to query the state of the migration process as depicted in Figure 15.


Figure 15. Query status for the Exchange_SG2 session A repeat interval “-i” (in seconds) can be specified in conjunction with the query command to show a continued output of the migration, including the calculated copy rate.

symmigrate query -sid 94 -name Exchange_SG2 -i 60

Additional parameters can also be included to verify the state of a migration, which might prove helpful in environments where the migration is scripted. When a verify state is specified with a repeat interval the command line or script will be held until the specified state is reached. One example would be to hold the command line until the Virtual LUN session is in a migrated state.

symmigrate verify -sid 94 -name Exchange_SG2 -migrated -i 300

When the migration is complete, the same symdev show command used in Figure 14 can be used to show the new mirror set information for the device. Figure 16 shows the end result while the session is in the “migrated” state. Notice now only the RAID 1 hyper type is reported.


Figure 16. symdev show command after the Virtual LUN migration

Upon completion of the migration, the original RAID group is automatically deleted and the devices are reformatted. The remaining step is to terminate the session, again by utilizing the session name as follows:

Symmigrate terminate –sid 94 –name Exchange_SG2

Following the terminate operation the migration process is complete. The database file mentioned at the beginning of this example is now serviced from not only a different disk type but also a different RAID type, without any interruption in service to the Exchange storage group and the users that it supports.

Striped metavolume expansion Storage administrators are continually looking for flexibility in the way that storage is provisioned and may be altered in-situ and online. Administrators in Exchange environments may find the need to increase storage for a given database due to an increased user count or change in mailbox size policies. One method to account for growth in a given Exchange database is to expand the LUN on which that database resides. Previous versions of Enginuity have provided for ways in which to grow Symmetrix volumes. The method to expand volumes in place and online would involve adding additional members to an existing metavolume. If the metavolume was concatenated, then only the additional volumes to be added to the meta would be required to expand the volume online with no disruption to the application. Striped metavolume expansion, however, required not only the additional volumes, but also a mirrored BCV in order to perform the expansion with data protection. The requirement for a mirrored BCV excluded other more cost-effective protection types, such as RAID 5, which may be more desirable for BCV volumes. With Enginuity 5874 and VMAX arrays, customers may now use other protection types for the BCV used in conjunction with striped metavolume expansion, including RAID 5 or RAID 6. The following section provides an example of online striped metavolume expansion using a RAID 5 BCV. EMC Symmetrix VMAX and Microsoft Exchange Server Applied Technology 22

Striped metavolume expansion example This example will be focusing on the same device, 41F and Exchange storage group that was migrated using Virtual LUN technology in the previous section. We will continue this example by expanding metavolume 41F with four new devices (42D, 42E, 42F, and 430) that reside in the same 15k rpm Fibre Channel disk group to which it was migrated. The RAID 5 BCV metavolume to be used in order to protect data during the migration, device 431, exists on a separate disk group. In preparation for expanding a striped metavolume with data protection, it is necessary to ensure there are no existing Symmetrix-based replication sessions occurring against the device. This includes ensuring TimeFinder, SRDF, and Open Replicator sessions have been removed, terminated, or canceled as appropriate to the respective technology. The requirement to remove all replication sessions also includes the BCV to be used for protecting data during the expansion. The BCV cannot be synchronized or otherwise have a relationship with the metavolume prior to running the expansion procedure using Solutions Enabler 7.0. It is also important to ensure that the devices being added to the existing metavolume have the same attributes. In this example the metavolume is a clustered resource within a Windows 2008 failover cluster. A Symmetrix device within a Windows 2008 failover cluster requires that the SCSI-3 persistent reservation attribute be set. Since at the beginning of this example the SCSI-3 persistent reservation attribute is not set on the volumes being used for the expansion, the following command needs to be issued: symconfigure -sid 94 -cmd "set dev 42D:430 attribute = SCSI3_persist_reserv;" commit

Once the environment is prepared, the LUN expansion can be executed. The expansion procedure will be executed from a host with gatekeeper access to the required Symmetrix using the symconfigure CLI command. Figure 17 shows the partition for the LUN in this example, as seen from the disk administrator, prior to it being expanded.

Figure 17. Striped metavolume prior to expansion

To expand the metavolume, the following command was executed:

symconfigure -sid 94 -cmd "add dev 42d:430 to meta 41f protect_data=true bcv_meta_head=431;" commit

Once the expansion process has begun, the following high-level steps will be taken: 1. The BCV metadevice specified for data protection will begin a clone copy operation from the source

metavolume. 2. During the clone copy operation, writes from an application, like Exchange, will be mirrored between

the source metavolume and the BCV. 3. When the BCV copy is complete, the BCV is split from the source and all read and write I/O is

redirected to the BCV device. 4. While the I/O is redirected, the source metavolume will be expanded with the specified volumes. 5. After the metavolume is expanded the data from the BCV is copied back and restriped across all

members of the newly expanded metavolume. 6. During the copy from the BCV, I/O is redirected back to the expanded metavolume.


7. Once the copy back is complete, the BCV clone relationship is terminated and the expansion

completes. Due to the nature of the volume expansion there will be a performance impact for reads and writes to the LUN. With this in mind it is recommended to perform any expansion operations during maintenance windows or times of low I/O rates to the LUN. The symconfigure command will monitor the expansion throughout the process as seen in Figure 18. Once the expansion is complete symconfigure will exit.

Figure 18. symconfigure command during the expansion process

After the symconfigure command completes, it is now required to extend the partition that resides on the now larger LUN. To do this the first step is to perform a rescan from the host via the disk manager GUI or the diskpart cli command. Once the rescan is executed the new size of the LUN should be seen from the host as depicted in Figure 19.

Figure 19. Metavolume after the expansion

At the completion of the metavolume expansion the diskpart command can be used to grow the partition into the newly discovered free space. From the diskpart command, either the volume or the partition needs to be selected prior to issuing the “extend” option. Figure 20 gives an example of using diskpart to select the target disk, followed by selecting the appropriate partition on the disk, followed by issuing the extend command.


Figure 20. diskpart commands to expand the NTFS partition The extend command will grow the partition into the free space on the disk, as shown in Figure 21. This completes the expansion process and the Exchange database can grow into the now larger volume on which it resides.

Figure 21. Metavolume following the diskpart extend command This particular example was tested on a Windows 2008 failover cluster while running a light loadgen workload against the database LUN being expanded (~200 IOPS). The ~88 GB LUN was expanded in roughly 35 minutes.

Volume management with Symmetrix Integration Utilities With the release of Solutions Enabler 7.0, the command line utility symntctl, also referred to as the Symmetrix Integration Utilities (SIU), is now included. The “typical” install of Solutions Enabler 7.0 will install the symntctl CLI onto Windows platforms automatically.

SIU integrates and extends the Windows 2003 and Windows 2008 disk management functionality to better operate with EMC Symmetrix storage devices. SIU provides particular value in environments where TimeFinder and SRDF are being used. SIU is not a replacement for the Windows Logical Disk Manager (LDM), but bridges lacking functionalities necessary for Windows Administrator to optimally work with EMC storage devices. Specifically, SIU enables administrators to perform the following actions:


• View the physical disk, volume, and VMware datastore configuration data. • Update the partition table on a disk. • Set and clear volume flags. • Flush any pending cached file system data to disk. • Show individual disk, volume, or VMware datastore details. • Mount and unmount volumes to a drive letter or mount point. • Manipulate disk signatures. • Scan the drive connections and discover any new disks available to the system. • Mask devices to and unmask devices from the Windows host. SIU has been updated to support the Symmetrix VMAX array, including support for masking operations (symntctl mask and unmask) that work in conjunction with Auto-provisioning Groups functionality.

It should be noted that the version of symntctl included with Solutions Enabler 7.0 is separate from and not dependent on the SIU Service. The symntctl cli functions that previously relied on the SIU service are now managed directly by SIU or the operating system, therefore the SIU Service need not be installed in order to utilize symntctl.

Conclusion The Symmetrix VMAX array is a revolutionary new approach to high-end storage and introduces a number of new hardware features such as the scalable Virtual Matrix interconnect design that allows the storage array to seamlessly grow from an entry-level configuration into the world’s largest storage system. Microsoft Exchange Server backed by the power and flexibility of the Symmetrix VMAX system marks a new standard for flexibility, consolidation, and performance in Exchange environments, providing improved performance and scalability for today’s and tomorrow’s demanding enterprise storage environments. The Symmetrix VMAX system running Enginuity version 5874 when used in conjunction with Solutions Enabler 7.0 provides many new features and functionality including Auto-provisioning Groups and Enhanced Virtual LUN Technology that improve data center efficiency. This increase in efficiency includes less administrative overhead, enhanced resource utilization, and lower power consumption. These benefits lead to a higher return on investment (ROI) and a lower total cost of ownership (TCO) for virtually all Microsoft Exchange Server environments.

References The following can be found on Powerlink, EMC’s customer- and partner-only extranet: • New Features in EMC Enginuity 5874 for Symmetrix Open Systems Environments (white paper) • EMC Symmetrix VMAX Best Practices Technical Note • Best Practices for Nondisruptive Tiering via EMC Symmetrix Virtual LUN Technical Note • Storage Provisioning with EMC Symmetrix Auto-provisioning Groups Technical Note


EMC Symmetrix VMAX and Microsoft Exchange Server · PDF fileEMC Symmetrix VMAX and Microsoft...

Documents

Transcript of EMC Symmetrix VMAX and Microsoft Exchange Server · PDF fileEMC Symmetrix VMAX and Microsoft...