Tag:

StoreServ

Peer Persistence brings Metro Clustering to 3PAR Storage

by Philip Sellers April 15, 2013

This is part 3 of a multipart series focused on 3PAR storage from an EVA Administrator’s perspective. Check out parts one and two – Understanding the 3PAR difference in array architecture and Learning the 3PAR lingo for the EVA administrator.

HP 3PAR Peer Persistence is the most exciting feature for me in the new 3PAR StoreServ 7000 series. I’ve referred to it has a ‘holy grail’ feature to my sales team and to our internal team at work. While its not the first to market with metro storage clustering, it brings the feature set to the 3PAR lineage and features a non-disruptive failover between the arrays. VMware officially started supporting metro storage clusters in 2011 with a limited number of storage vendors and solutions and as of posting, 3PAR does not have official support stated from VMware, but it should soon.

Peer Persistence rides on top of the Remote Copy replication feature set and uses synchronous replication. The two key pieces to the Peer Persistence solution are assigning the secondary copy the same volume World Wide Name (WWN) as the primary and the use of Asymmetric Logical Unit Assignment (ALUA) on the VMware side to recognize the active paths when a failover is invoked. To a VMware host, you see active and standby paths to the VLUN thanks to the shared volume WWN.

EVA Administrators are experienced with ALUA for finding and using the optimized active paths to a LUN. On the EVA, only one controller has true write access to the LUN and the paths to that controller are marked as “Active (I/O)” and the paths to the secondary controller are marked as “Active”. The secondary paths would not be used for IO.

Within 3PAR, Peer Persistence uses the same ALUA technology to discover the active paths to the active array and to set the paths to the target/secondary 3PAR array into StandBy mode. It is also critical in the discovery of a switchover condition where the primary paths become blocked, ALUA issues a discovery command the the Secondary array’s paths are found as active. With the 3PAR, all paths to the active array are labeled as “Active (I/O).”

Is Peer Persistence right for your environment? Let’s start with the list of requirements:

Close proximity of your two datacenters with large pipes and low latency.
The ability to perform synchronous Remote Copy between your 3PAR arrays in 1-to-1 configuration.
- Requirements of Synchronous Replication
The volumes exported from primary and secondary must share the same volume WWN.
ESX hosts must be 5.0 or higher and must be exported with host persona 11 (VMware)

Clearly, this isn’t for everyone. The fact that you must be within synchronous distances for replication is a deal breaker for many customers, but not all.

Setup Peer Persistence

Peer Persistence sets up just like any other Remote Copy scenario. I won’t cover that in this post, but I suggest you check out the HP 3PAR Remote Copy Software User’s Guide for all the details on setting up Remote Copy in various scenarios and for more details on Peer Persistence.

After you have created your Remote Copy group with virtual volumes inside and before you export the volumes to the hosts, changes for Peer Persistence are necessary. On the Primary 3PAR array, you will need to enumerate a list of the virtual volumes including their WWN. You can display this in the 3PAR CLI using the showvv command.

[sourcecode]showvv -d <vv_name>[/sourcecode]

The output should be a single line including the WWN of the virtual volume. I suggest that you highlight and copy the WWN for use in the next step.

Next you will assign the secondary virtual volume the same WWN. Open a 3PAR CLI connection to the secondary 3PAR array and in this CLI environment, you will issue a setvv command.

[sourcecode]setvv -wwn <WWN> <vv_name>[/sourcecode]

On the secondary array, issue another showvv command and confirm that the WWN on the secondary now matches the WWN on the primary.

Once you have completed the WWN assignment on the secondary volume, you may start replication and export the Virtual Volumes to the hosts. When exporting, ensure host person 11 (VMware) is used for all hosts.

Invoking a switchover

A switchover is easy. From the 3PAR CLI, a single command will allow you to switch over an entire Remote Copy group of Virtual Volumes or all Virtual Volumes with Remote Copy targeted to a specific 3PAR array. However, there are several piece of information you will want to check before issuing the switchover command.

To find the names of the Remote Copy groups and/or to see which Remote Copy groups are targeted towards a particular 3PAR array, you issue the showrcopy command in the CLI. In the output, you will find the name of the Remote Copy group and the array it is targeted to replicate to. A sample of showrcopy output is below:

With the information, you can initiate a switchover from primary to secondary with no interruption in service. From a showrcopy output, you can determine which target 3PAR array is part of the synchronous replication (outlined above in green). The target name can be used to failover all Virtual Volumes hosted by this 3PAR array to the target/secondary array for those VV’s.

Otherwise, if you want to issue the The switchover is initiated from the primary array for an Remote Copy group, so you will want to look at the Role column (outlined above in blue) of the Group Information in the output. In this example, only sync_group_1 may be issued the switchover command on this 3PAR array. To failover sync_group_2, you must connect to CLI on the System2 3PAR array. To failover a Remote Copy group of Virtual Volumes, you have to issue a command using the Remote Copy Group name (outlined above in red). You should also ensure that Remote Copy is running and in Synced status by checking the SyncStatus column (outlined in orange above). In our example above, you will need to wait for syncing to complete for localvv.0 and localvv.1 before issuing a switchover command.

Failover all volumes replicating to a Target 3PAR

Taking the target 3PAR array name, outlined in the example in green, issue the following command:

[sourcecode]setrcopygroup switchover -t <target_name>[/sourcecode]

Using the output from our example, we would issue the following:

setrcopygroup switchover -t System2

Failover a particular Remote Copy Group

To switch a particular Remote Copy Group, take the remote copy group name – for instance sync_group_1 from the example above and issue this command in the 3PAR CLI:

[sourcecode]setrcopygroup switchover <group_name>[/sourcecode]

For our example with sync_group_1, you would run:

setrcopygroup switchover sync_group_1

Within a matter of seconds, the 3PAR arrays will fail from the primary to secondary and your active and standby paths will switch in VMware.

Behind the Scenes

Behind the scenes, the primary 3PAR array is in control of the synchronous Remote Copy. The primary array stops accepting IO on its interfaces, commits all writes, then swaps control to the secondary array which then opens its paths and begins accepting IO. At the same time, the VMware hosts are notified that the path is blocked and it initiates a ALUA discovery to find its active paths.

In part 4, we will focus on best practices for vSphere 5.1 with the 3PAR StoreServ 7200/7400 arrays.

April 15, 2013 14 comments

Datacenter Storage

Learning the 3PAR lingo for the EVA administrator

by Philip Sellers April 8, 2013

written by Philip Sellers

This is the second part of a multi-part series about 3PAR from an EVA administrators perspective. See Understanding the 3PAR difference in array architecture for the first part of the series.

One of the most daunting thing about moving from EVA to 3PAR is the change in terminology. While the concepts of many things are the same between the two architectures, what they’re actually called is a completely different matter. So the best place to start is with the brain.

Controller versus Node

EVA have two controllers, regardless of which model. Each controller has its own connectivity, however only one controller at a time can be in charge of any individual Vdisk.

With the 3PAR, a StorServ 7400 or 10000 series can scale up from an initial 2 nodes to 4 or 8 respectively. Each node installs in pairs. Each node is equipped with dual Intel Xeon Processors. And each one of the nodes has full control over the storage which sits behind it, increasing throughput and scalability far beyond what EVA can handle. The nodes are configured in an Active Mesh architecture where each node is cross connected with each other in a fully redundant way.

Disk Groups versus CPG’s

Disk Groups are a physical grouping of disks used for creating Vdisks. Common Provisioning Groups (CPGs) are a bit more than just a group of physical disks. CPGs are a group of properties of how virtual volumes (VV) are created and where the EVA disk groups are a physical divider, CPGs can share all or a part of the same physical disks.

CPGs include properties like the RAID type, the device RPM, the device type and domain. All these properties go towards defining a class of storage for a particular use. The CPGs are reusable profiles that can be chosen when carving out VV’s.

Presentation versus Exporting

EVA has Vdisks and 3PAR has Virtual Volumes. Its basically the same, its a section of storage carved out of a EVA disk group or 3PAR common provisioning group (CPG), respectively. On the EVA, you present your Vdisk to hosts. On the 3PAR, its a slightly difference process. You take Virtual Volumes (VV) and you export them to hosts. Each export becomes a VLUN, which is a single path from host to virtual volume. Its a small but important difference, in that it gives you an additional level of control needed due to the possibility of many ports to present from. The 3PAR is slightly more intelligent – it senses which paths are zoned or exposed to the host and where it is visible. With the EVA, you use all available paths, but with a 3PAR and the possibility of up to 72 PCI slots in a fully populated StorServ 10800, presenting from all simply doesn’t make sense. In addition, a single 3PAR can be used for both Fiber Channel, Fiber Channel over Ethernet or iSCSI all from the same box. But, the process is roughly the same – you match a Vdisk or VV to a host and you export.

EVAPerf versus System Reporter

In all honesty, comparing System Reporter to EVAPerf does it a great disservice. EVAPerf, while adequate, never quite gave administrators enough information and certainly never equipped them with tools to do historical analysis of performance. System Reporter for 3PAR is a much more capable set of performance analysis software. While you can see real-time performance through the Management Console, System Report collects data into a separate database and allows administrators to configure and create reports, even scheduling them to run automatically and email. System Reporter is a lightweight web application that runs separately from the 3PAR arrays and storage processors. It sits to the side and quietly collects metrics for consumption after the fact. System Reporter offers views into the performance of physical disks, virtual volumes, host ports and remote copy ports among other things. Administrators looking for real-time analysis should look to the Management Console.

Chunklets

I just have to mention chunklets. First, the name just makes me laugh a little when I hear it. It sounds like something that happens after a night of too much partying. But chunklets are really the basis of data within the 3PAR arrays. All data is ultimately split into chunklets and spread across the disks of the array. While the EVA did a similiar thing by spreading bits of the data across disks in the disk group, chunklets are not bound to a grouping and can move across any of the disks in the array as long as the CPG they belong to allows it. (CPGs can limit operations to a specific group of disks, if you wanted or needed). Chunklets are also the basis at which analysis and autonomic optimization occurs. When Autonomic Optimization is licensed and enabled on an array, each chunklet is analyzed in order to know whether it should be promoted or demoted to a different class of drives in the array – SSD, SAS or near line.

Comparible Terminology

EVA P6000	HP 3PAR StoreServ
Controller	Node
P6000 Command View	HP 3PAR Management Console (MC)
SSSU	HP 3PAR CLI
XCS	HP 3PAR Operating System (previously HP 3PAR InForm OS)
PSEG	Chunklet
Vdisk	Virtual Volume (VV)
Disk shelf	Drive chassis
Vraid	RAID
Thin provisioned	Thin Provisioned Virtual Volume (TPVV)
Vdisk presented to a host	VV exported to a host
Disk Group	Common Provisioning Group (CPG)
Business Copy	Virtual Copy
Continuous Access	Remote Copy
Host Operating System Type	Host Persona
EVAPerf	System Reporter
Online Disk Migration, Leveling	Dynamic Optimization (DO)
Initialize the system	Execute Out-of-the-Box (OOTB) procedure

Source: An Introduction to HP 3PAR StoreServ for the EVA Administrator

In part 3, we will dive deep into the 3PAR StoreServ 7200 & 7400’s Peer Persistence technology for metro clustering.

April 8, 2013 1 comment

Datacenter Storage

Understanding the 3PAR difference in array architecture

by Philip Sellers April 1, 2013

written by Philip Sellers

I have been working on this post for well over a year, but it never made it out of my drafts because I didn’t feel comfortable with 3PAR. That all changed this year with the purchase and implementation of two 3PAR StoreServ 7000 series arrays. As an HP EVA customer, 3PAR has always been a compelling alternative, even before HP’s acquisition. The technology looked like close cousins to me. With HP’s introduction of the 7000 series at the end of 2012, it became even more clear this would be our future storage platform and I suspect the future platform for many EVA customers. This post is the first in a multi-part series about 3PAR from an EVA administrator’s point of view.

Close cousins, but different in important ways

Bottlenecks and single-points-of-failure seem to be the two things I combat most as a systems administrator. As a systems admin, you try and identify these points and plan for redundancy and capacity. We have to serve as the realists and the ‘doom-and-gloom’ guys because we plan for the worst case. When applying that concept to storage, it meant that we must purchase an array for our peak performance periods and we would need to often purchase more arrays to combat the problem of at most two controllers in an modular array.

But, newer arrays have come to market with much different architectures which directly combat the bottleneck problems we have traditionally observed in modular arrays. We have seen industry standard servers employed at storage controllers over a cluster of systems to create arrays (like HP’s Lefthand or VMware VSA solutions) and we have seen scale up architecures like the 3PAR StoreServ arrays which have an active-active mesh of up to 8 controllers to increase the performance.

The active mesh architecture is the first big difference between our EVA’s and a 3PAR StoreServ. In an EVA, only a single controller may truly access and control a LUN at any given time. Any requests received through the other controller are simply proxied over and handled by the controlling controller. In the 3PAR, all controller nodes access and own the LUN and can service requests to it. All of this activity is sent across a passive, full-mesh backplane which connects the controller nodes to each other and to the storage shelves. The nodes are connected across high-speed links (800 Mbps in each direction), but also have a low-speed RS-232 serial link for redundancy for control information between nodes in case the main links fail.

The second difference in architecture is related to scale and modularity. When you purchase an EVA, you get two controllers and that’s all it’ll ever have. With a 3PAR array, you can start with two controllers and scale up to a total of 8 controller nodes as your needs increase, depending on the line. The 3PAR StoreServ 7200 is limited to 2 controllers and the 7400 can scale from 2 to 4 controllers, while the 10000 series continues to scale to 8 controller nodes. This is a particular advantage when looking at cloud architecture which has increased the overall utilization of controllers and taxed them to the point of bottleneck on my arrays. HP has touted the P10000 3PAR method of modular controllers as the answer to cloud scale issues. While administrators must still size arrays to the peak, there is some ability to purchase what is needed and then scale up the controllers for the future, where its not possible today in the EVA line.

3PAR StoreServ can also address several storage tiers with different types of storage, mixing and matching volumes across types of storage as needed. While it was also possible to create multiple disk groups in EVA — one with traditional Fiber Channel drives and one with solid state drives, for instance — the EVA does not allow for mixing and matching data across multiple disk groups. With the 3PAR, however, autonomic storage tiering is a software feature of the array that allows chucklets of data to be spread across types of disk. The array can auto-magically determine where things should optimally be stored based on how often and how quickly they need to be access and move them from SATA to SAS to solid-state disks accordingly. This all occurs without an administrator having to actively manage it.

Thin provisioning is the probably the biggest difference between the arrays — not from a pure capability comparison but from how its employed in the array. Since the 3PAR aquisition, HP has brought thin to the EVA line, so from a check box perspective, they both have it.

But 3PAR utilizes thin throughout its architecture. Thin is fully baked in the the 3PAR ASIC (or application specific integrated circuit) and so it is available at the lowest levels of the array. The array allows for fat to thin conversions of data non-disruptively through its proprietary algorithm. Replication is also handled using the thin-built-in technology through zero detection. Zero Detect, as the HP folks brand it, is a technology which detects and strips zeros from streams of data which makes it possible to no only encode data in a thin fashion on write, but also take data at rest and convert it to thin provisioned data in a timely manner.

Since the HP acquisition of 3PAR, they have worked to make data more portable between storage platforms. Peer Motion was introduced during VMworld 2011 and it is federation technology and allows for zero-downtime relocation of storage from one array to another. Peer Motion is more in line with Storage VMotion in vSphere than a replication technology. The majority of the work is handled on the destination system which is receiving the storage volume. HP has introduced Online Migration, a one way migration from EVA to 3PAR StoreServ. For EVA shops, this is an important technology – since it will allow for non-disruptive moves of data from your EVA to a 3PAR array. The migration is configured through CommandView and at a basic level, involves the 3PAR fronting the EVA’s LUNs to the host and then transparently migrating the data behind the scenes until its all moved to the 3PAR and then removes the link to the EVA. Peer Motion is a major enabling technology for companies looking to migrate data in an automated way.

Stay tuned for part 2, launching next week, where we go deeper on 3PAR terminology for the EVA administrator.

April 1, 2013 1 comment