Around the Storage Block Blog : EVA

Day 3 from TechEd

CalvinZ — Thu, 12 Nov 2009 15:55:00 GMT

By Ian Selway, Worldwide HP StorageWorks Solution Manager

I've just arrived back from London and I'm looking forward to Day 3 at Microsoft TechEd Berlin. Today we've supported Microsoft in their exhibition area, manning a partner kiosk and demonstrating our LeftHand and EVA integrations with Microsoft Server 2008 R2. We had Matthias Popp from our SSI team present on this integration during Microsoft's Multi-Site Clustering with Windows Server 2008 R2. It was a full session with over 300 delegates in the room, and a further 120 or so who couldn't get in. Matthias received a large ovation after his presentation, and a good deal of the Q&A at the end focused on what we could do with LeftHand and EVA and Microsoft Live Migration. As with previous days, traffic in the exhibition halls was very busy and there was lots of interest especially in our MDS600 tear down unit. I spoke with one customer from the UK who wants to take the unit home as he has an immediate demand for this type of JBOD unit to provide him lower cost bulk storage for his Exchange users and to archive off his SAP database. The way he sees it, he has a 400GB SAP database and he's more than happy to give them a 1TB SATA drive in the MDS600, and let them have as much space as they want. He also salivates at the thought of offering his mail users 5, 10 or even 20GB mailboxes because of the bulk storage he'd have with the MDS 600.

Another customer we met with today is a large Swiss company who are about to run a proof of concept with Server 2008 R2 and was pleasantly surprised with the Live Migration capabilities of EVA with CA/CLX. It bodes well for the testing and they should make a great reference customer for us, if they deploy as planned. The Microsoft virtualization marketing team were really happy with our support of their partner kiosk, and we spent time with them exploring where we could work together in future engineering and marketing activities to further promote our abilities together.

Tonight is a customer appreciation event in partnership with Brocade and AMD. It promises to be a great evening and apparently there's an all female brass band called the Venus party band so if you can read German you're welcome to explore what we're in for. More from TechEd day 4 tomorrow.......

(Editor's note: I'm leaving on vacation tomorrow morning; Ian's Day 4 post up may not happen until I return.)

Converged Infrastructure: Block based storage virtualization podcast

CalvinZ — Fri, 06 Nov 2009 17:55:00 GMT

By Calvin Zito, @HPStorageGuy

This is the third in a series of three podcasts focusing on our HP Converged Infrastructure announcement. In part 1, I spoke with Sr. VP and GM of HP StorageWorks Dave Roberson. In part 2, I talked to the former CEO of IBRIX Milan Shetti and Marketing Director Lee Johns about the new X9000.

In today's podcast, we talk about block-based storage virtualization. Storage virtualization is often a confusing topic because there are different types of storage virtualization. Today's podcast discusses two types of block-based storage virtualization: within an controller array (like our HP StorageWorks EVA) and network or SAN based (our StorageWorks SAN Virtualization Services Platform or SVSP). Each of these products had enhancements that were announced with the November 4th Converged Infrastructure announcement.

With the SVSP (link goes to the hp.com product page), we announced a "new" management tool - Command View SVSP. This will be very familiar tool to EVA customers as Command View SVSP is very consistent with Command View EVA. But it also simplifies and automates the task of provisioning a LUN. For the details, listen to the podcast.

The advancement with the StorageWorks EVA (link goes to EVA family page) is with our Cluster Extension EVA. This software manages the failover and failback between EVAs in a cluster. What's new with the software is support for Microsoft Hyper-V Live Migration. We are the first array to support the new capabilities and again, there's more about this in the podcast. I also have a guest blog from one of our engineers below that goes into more details.

So with that, here's the podcast:

If you're browser has issues using the embedded player, click here to listen to the podcast with a different player. Here's a link to download the MP3 (right click and save the file).

By Matthias Popp, HP StorageWorks Architect, Storage Systems Integration

Migrating a running server across data centers, servers and storage?

Are you tired of planning weekend downtime for storage system upgrades, server patches or network changes in your data center? Are you getting the same "Not this weekend ..." response from your business managers and users?

HP worked with Microsoft to enable Live Migration of virtual machines (VMs) in Hyper-V R2 - not just between servers but also between your storage systems and hence between your data centers!

The latest release of HP StorageWorks Cluster Extension EVA orchestrates the interaction between Microsoft's System Center Virtual Machine Manager, Windows Failover Clustering and Hyper-V Live Migration to move running Server VMs between servers and storage in one single step.

The newest version of Cluster Extension checks the disk array replication process and prepares for a Live Migration and swaps the replication direction when the VM's target server is connected to the remote disk array. All automatic with no further administrator interaction. You decide when to Live Migrate and Cluster Extension makes sure the data can be accessed. Simple as that.

Since your servers and storage are distributed between data centers, the same configuration and software is used for disaster protection. No need to learn additional tools. Use the ones you have!

Finally a simple solution to proactive maintenance with no downtime!

The new Live Migration support in Cluster Extension configurations will make a radical impact on your IT and business teams. Clustering software manages unexpected failures at any time and Live Migration enables maintenance during the work day. The IT team can now do server and storage maintenance during working hours. They no longer have to plan for downtime way ahead of a change. The IT management doesn't have to budget for expensive weekend and night working hours. Get your server and storage patched now, because you can!

The following paper explains the configuration and will soon be updated for Windows 2008 R2 and Hyper-V R2 Live Migration support: Disaster Tolerant Virtualization Architecture with HP StorageWorks Cluster Extension and Microsoft Hyper-V^TMwhite paper

Visit the HP booth at Microsoft's Tech·Ed Europe in Berlin next week for a demonstration and visit Microsoft's blog for more info about the webcast Building Effective and Highly Available Disaster Recovery Solutions Using Microsoft Virtualization

What will EVA customers benefit from new NetApp program be? Zip! Zilch

CalvinZ — Mon, 02 Nov 2009 15:51:00 GMT

By Calvin Zito, @HPStorageGuy

In my last post, I included a couple of summary videos from our recent HP StorageWorks Tech Day. The hands-on lab really stirred up a few folks over at NetApp. The week after our Tech Day, they did a WebEx session to try to address some of the comments made by the bloggers about how difficult the management of their FAS system was. I won't go into details about that but I counted at least three different GUIs that they showed during that demo. The HP StorageWorks EVA has one - Command View. But, that's not the topic I want to cover today.

The old "switch-a-roonie"

During their online demo, Vaughn Stewart from NetApp also discussed the NetApp vSeries - a network based storage virtualization product - and suggested that HP and NetApp were partnering to help EVA customers. Vaughn thanked me for attending the demo and talked about partnering with HP. I thought he was trying to connect the fact that I attended as being an HP endorsement of the vSeries. It wasn't. I made it very clear that HP wasn't working with NetApp to put vSeries products in front of our EVA's. I told the demo audience that HP has our own network-based SAN virtualization product called the SAN Virtualization Services Platform (SVSP) that competes with the vSeries and in no way do we recommend EVA customers use the vSeries to virtualize a pool of EVAs. We have talked about the SVSP several times on this blog and it will be discussed in a podcast later this week.

I initially didn't understand why Vaughn brought the vSeries into the demo. But a week or two after the NetApp demo, they announced a new marketing program targeting EMC CX series and HP EVA installed base customers with their vSeries. Now it's pretty clear to me what was going on then. This new NetApp marketing program asks customers to consider putting a vSeries in front of an EVA or CX.

So I want to spend a few minutes now discussing why I think it would be a bad decision for any EVA customer to consider such a thing. It's my belief that the benefits to an EVA customer would be zip (and interestingly that is the name of NetApp's program).

Improve storage efficiency at what price?

The claim NetApp is making is that EVA customers are not efficiently using their storage capacity. That's a bit laughable given that with an EVA, every spindle is used for data and unless using tiering, we recommend a single disk group which gives incredible storage capacity efficiency. To be in the program, NetApp has to approve the customers' application. The customer is basically signing up to purchase the vSeries in 90 days if it delivers what NetApp will stipulate. Be sure NetApp also stipulates the peformance hit you'll take - but I'm ahead of myself on that one.

My guess is the number of customers that actually get into the program will be rather small and maybe that's a NetApp objective of their marketing program. I suspect that NetApp's real motive is to develop a list of CX and EVA customers that they can continue to call on.

The NetApp claims of improved storage efficiency will come from a couple of categories of services that the vSeries provides for the arrays attached to it.

Thin provisioning
Data replication (snapshot, clones, etc)
Deduplication

The EVA customer already enjoys capacity efficiencies with the first two categories of thin provisioning and data replication. (Note that the EVA doesn't use traditional thin provisioning today but uses a product called Dynamic Capacity Manager that accomplishes similar results by integrating with the OS).

For that matter, if customers wanted to pool their capacity of multiple EVAs and manage it as one pool, the SVSP offers thin provisioning and replication services too. What we don't offer today is primary LUN deduplication. But should customers running an EVA rush to deduplication their block-based mission critical storage? I think the answer is absolutely not and here's a few things to consider:

NetApp has recently claimed 37,000 deployments of deduplication (via their PR department) but in a recent earnings call, their executives said 37,000 downloads. I don't know about you but there's a big difference between the number of customers who download some free software versus who are actually using it, especially in production environments.
There's a trade-off to implementing deduplication with primary, block based storage - and that trade-off is performance. Data that I've seen from a few different sources has said that a top customer concern in a virtualized environment is performance. I've seen throughput testing results that say the performance degradation on a FAS system with dedup can be as high as 65%. Their own recommendations say to run it during low activity and not all of the time. NetApp also makes you sign a waiver stating you understand the risks of lower performance.
We haven't tested to see what the actual deduplication capacity savings would be and frankly there are a lot of factors that would play into that. Since the controllers in the vSeries are the same controllers in the FAS system, it's worth noting that we have found that the percentage of capacity savings is roughly equal to the percent of slowdown.
And that performance hit from deduplication doesn't include any other latencies that the vSeries introduces because of their in-line architecture.

So should an EVA customer put their arrays behind a NetApp vSeries for a potential small capacity savings when the potential performance penalty is high? And keep in mind the vSeries is based on the FAS controller. We've shown in a recent blog post that based on our testing, the performance of that degrades rapidly.

There are some good reasons to implement SAN-based virtualization with a product like the StorageWorks SVSP or the NetApp vSeries. However, for an EVA customer, NetApp's value proposition of getting better capacity efficiency of the physical storage just isn't one of them. A far better answer for the EVA customer is the StorageWorks SVSP. We'll cover this topic in podcast later this week so stay tuned for that.

Tweet this!

StorageWorks Tech Day starting now

CalvinZ — Mon, 28 Sep 2009 04:43:00 GMT

By Calvin Zito

If you don't follow me on Twitter, you may not be aware that we have a blogger event going in on Colorado Springs. We've brought a number of prominent storage and virtualization bloggers and over the next day and a half, have a packed agenda. The topics we'll cover include:

Storage virtualization for enterprise customers - virtualize infrastructure, not just servers
Shared storage for virtual servers (SMB-focused)
Unified storage
Deduplication
Converged Infrastructure

We'll also have hands on sessions and demos of the HP StorageWorks Enterprise Virtual Array (EVA), SAN Virtualization Services Platform (SVSP), and HP LeftHand. Here's a list of who is here (the "@name is their Twitter user name):

Rich Brambley (@rbrambley) http://vmetc.com
Nina Buik (@NinaBuik) Connect Community (its a long URL so this is a hyperlink)
Stephen Foskett (@sfoskett) http://blog.fosketts.net
Robin Harris (@StorageMojo) http://storagemojo.com (Robin has already post a blog - click here to see it)
Greg Knieriemen (@Knieriemen) http://www.storagemonkeys.com/index.php?option=com_myblog&Itemid=136
Ray Lucchesi (@RayLucchesi) http://silvertonconsulting.com/blog/
John Obeto (@JohnObeto) http://absolutevista.com
Frank Owen (@fowen) http://techvirtuoso.com
Devang Panchigar (@StorageNerve) http://storagenerve.com (Devang also posted a blog - click here to see it)
Nigel Poulton (@nigelpoulton) http://blogs.rupturedmonkey.com
Simon Seagrave (@kiwi_Si) http://www.techhead.co.uk

I'm grateful to all of them for taking time out of their busy schedules to learn more about HP StorageWorks.

I'll be blogging here about what is going on and hope to have a few podcasts later in the week. If you want to follow the conversation real-time, we'll be using the hashtag #HPTechDay on Twitter. If you don't use Twitter, here's a URL where you can see all of the "tweets" using this hashtag: http://search.twitter.com/search?q=%23HPTechDay.

Tweet this!

HP Storage Essentials Performance Edition

CalvinZ — Fri, 05 Jun 2009 15:48:00 GMT

By Calvin Zito

HP Storage Essentials Performance Edition (this is a link to the product page) provides path-aware performance management of your HP storage arrays (EVA and XP) and SANs while delivering a structured approach to resolving and identifying path performance issues. Key to Storage Essentials Performance Edition is the ability to Optimize, Monitor, and Analyze performance, application and capacity issues:


•	Optimizes... storage performance for host virtual environment and troubleshoots storage performance issues easily
•	Monitors... the entire application storage path for performance and capacity to meet or exceed storage service SLA
•	Analyzes.. historical performance and capacity trends to fix problems proactively to maintain Storage service level agreements.

HP Storage Essentials Performance Edition two solutions,


•	HP Storage Essentials Performance Edition 150 software for HP StorageWorks EVA environments
•	HP Storage Essentials Performance Edition 300 software for HP StorageWorks XP environments.

Each package provides support for one array and one application instance (Oracle, SQL Server, Exchange) over a SAN with pre-defined number of managed access port (a host, storage, or SAN port). Finally, you might also find the data shee for Storage Essentials Performance Edition useful.

Tweet this!

StorageWorks EVA wins best hardware at Microsoft Tech Ed 2009!

CalvinZ — Thu, 14 May 2009 17:10:00 GMT

By Calvin Zito

Last week I had heard that the HP StorageWorks EVA was selected as a finalist at Microsoft Tech Ed 2009 for the category of best hardware, networking, or storage. I just learned that the EVA has won! (See this article on IT Windows Pro website). Congratulations to the EVA team.

My question after seeing this was what is the criteria for this award. Here's what I found out from the program overview:

These awards recognize the innovative products and services showcased at Microsoft Tech·Ed North America 2009. All Microsoft partners exhibiting or sponsoring at Tech·Ed North America 2009 were eligible to submit nominations for their products/services. The winners were selected by a judging panel of editors from Windows IT Pro and SQL Server Magazine, and are evaluated based on each finalist's strategic importance, competitive advantage, and value to customers.

Since we're on the subject of the EVA and Microsoft, I wanted to follow-up on yesterday's post about the EVA in VMware environments, today focusing on the EVA in a Microsoft Hyper-V environment. This video has our Senior Vice President and General Manager of HP StorageWorks Dave Roberson and Jim Schwartz and Jeff Woolsey of Microsoft talking about how the StorageWorks EVA storage solution delivers best-in-class performance when customers use Microsoft Hyper-V virtualization technology.

(Please visit the site to view this media)

A great day for the HP StorageWorks EVA!

Tweet this!

Optimizing infrastructure with VMware and the EVA

CalvinZ — Thu, 14 May 2009 00:24:00 GMT

By Calvin Zito

In early March, we announced the new EVA6400 and EVA8400 - we talked about that on this blog (see my post titled Storage Virtualization and the new EVA). The EVA is really a great match for virtual server environments. Here's a video that includes our Senior VP and GM of HP StorageWorks Dave Roberson and Parag Patel, VP of Alliances, ISV and Storage Ecosystem at VMware.

There's also a video I've seen with Paul Maritz (President and CEO of VMware) talking about the HP BladeSystem Matrix and our HP LeftHand Network products - unfortunately, I can only find it on a server inside the firewall . As soon as I can get a version that for you to check out, I'll add it too.

(Please visit the site to view this media)

And have I mentioned lately that the EVA has solid state storage technology... and that's about 12 months sooner than some of the FUD a certain competitor was spreading in their blogs.

Don't forget you can follow me on Twitter. Go to http://twitter.com/HPstorageGuy. I won't ever tell you what I had for breakfast!

Tweet this!

EVA Simplicity Challenge

CalvinZ — Fri, 24 Apr 2009 22:05:00 GMT

Back in early March, I talked about our storage virtualization announcement and pointed you to a video we did on the EVA. Well, I think I finally figured out how to embedded video in the blog (at least from YouTube), so I wanted to mention it it again and embedded the video. But first, here's a bit about the video.

Last year when we announced the EVA4400, we were just wrapping up some work with the Edison Group where we measured the time it took to perform specific storage administrative tasks on an EVA, Clariion CX, and NetApp FAS array. As a follow-up to the EVA4400 announcement, we brought some IT administrators to HP and asked them to perform a number of tasks on an EVA and Clariion array. The video was pretty good and was well received. So as we were getting ready to announce the EVA6400 and EVA8400 this year, we wanted to do another video to show just how easy the EVA with it's unique virtualization is to manage compared to competitive traditional arrays.

My original idea was to use either high school or college students; we'd have two groups - one a few football players and the other students taking high-tech classes. I was very confident that if we asked the football players to configure the EVA's and the tech students to work on the competitve arrays, the EVA would win hands down. A few folks on my team thought this could be a bit offensive, suggesting you really don't have to be educated to be an IT administrator. I saw it very differently - if HP StorageWorks can make products that simplify the time it takes to administrate their storage, that's really what our customers need - make it simple! I think the idea we used works just as well - we had three teams of high school students who each were asked to perform the same tasks on an EVA, Clariion CX4, and NetApp FAS array. As you'll see in the video, it appears as though the NetApp results are close but this is a bit misleading as we had to tell the students to skip some tasks on the FAS because no one could figure out how to do them.

With that background, there's the video:

(Please visit the site to view this media)

Come on - is the EVA really that easy to manage?

CalvinZ — Fri, 13 Mar 2009 20:31:00 GMT

By Calvin Zito

As I mentioned in my post titled Storage virtualization and the new EVA, the StorageWorks EVA is proving itself to be far easier to manage than competitive traditional disk arrays. Let me give you some of the back story here.

Last year, we commissioned an analyst team (The Edison Group) to measure the steps, clicks, and time it took to perform the most common array administrative tasks on several midrange arrays. They wrote a paper about those findings called "TCO White Paper: EMC, NetApp, and HP Midrange Storage Arrays". To be blunt, the paper never really measured TCO and in the end I thought it was the wrong title but it was still a good thing to see the time savings that we get with the EVA versus other arrays.

As I discussed in my post titled "Must See TV: EVA, EMC, and NetApp Go Head to Head" we brought customers to Houston to run some testing for us. You can find the video in the Must See TV post but there was also a white paper titled "Competitive Testing of Common Administrative Tasks" that gave more details on what happened through that testing. Again, interesting but still didn't give me what I wanted to see - how much can a customer save.

Fast forward to pulling together our announcement for the new EVA6400 and EVA8400. The thought was to do a survey of storage administrators on how they spend their day - meaning how often do they perform these different administrative tasks on their storage arrays. It seemed to me that if we had that data, we could then get to a time or cost savings when managing an EVA. This approach hit paydirt! Because the Edison Group had done the original testing, we turned to them again to survey administrators and calculate the savings. The paper based on this research is called "Comparative Management Cost Survey" Let me briefing summarize the results:

The total workday savings of an organization using an EVA as compared to EMC is 36 percent. When compared to NetApp, the savings are 50 percent. Workday savings is a term Edison uses to describe the value of an employee's daily work averaged over a year.

So when you hear us say the EVA costs up to 50% less to manage than other competitive traditional disk arrays, you know now why we can confidently say that. If you aren't using EVA's today, can you really afford to spend 2X managing the other guys' arrays, especially in today's economy?

One last point - I'm sure the competition will try to come up with 30 different reasons why our conclusions are wrong. EMC already tried to debunk the original Edison report by having an EMC engineer perform the same tasks on a Clariion and time the results they got. Well, duh! If I have an EVA engineer do the same tasks that Edison did I'm sure they'd complete them faster too. I would love to put all of these products to a joint test - have the best and brighest engineers from each company perform these tasks on their own storage array and everyone posts the results to their website. Somehow I don't get the sense that this is a challenge that either EMC or NetApp will want to touch.

Have a great weekend!

Must see TV: EVA, EMC, and NetApp go head to head

CalvinZ — Fri, 13 Mar 2009 04:03:00 GMT

By Calvin Zito

Last year when we announced the EVA4400, we brought some customers and partners to Houston who were not familiar with the management of either the EVA or EMC Clariion CX array. We gave them a list of tasks to complete and then created a video of that. It was one of the most popular videos of the last year on hp.com. The test showed that for the tasks these customers were asked to accomplish, they clearly thought the EVA was far easier to manage.

As we were preparing to announce the EVA6400 and EVA8400, we wanted to create an interesting video that would again make the point of how easy the EVA is to manage compared to competitive disk arrays. So the idea that we came up with was to have some high school students who are taking technical classes at their local high school (e.i. technology saavy) but not SAN or disk array experts put the EVA and competitive arrays to the test. The result is the HP StorageWorks EVA Simplicity Challenge. I don't want to spoil the fun for you but I'll make one comment about the results - the only reason the NetApp FAS system was even close was because no one could figure out how to do a snapshot on the NetApp system. So while the results look close, I personally thought we should have elimimated them from the results all together but we decided to keep their results in the video and note that doing the snapshots was beyond the scope of the test (in other words, was way too hard to figure out).

By the way, I wonder if my EMC blogger buddies have noticed that the EVA now has SSD drives - about a year a sooner than they predicted because to paraphrase their point of view, HP is a server company and can't innovate in storage. Of course, EMC doesn't have a virtualized storage array so what else can they say!

Storage virtualization and the new EVA

CalvinZ — Thu, 12 Mar 2009 19:04:00 GMT

By Calvin Zito

In my first post, I gave an overview of the March 10 announcement we did. In part 2, I gave a bit more color to the StorageWorks piece of the announcement. Today, I want to talk about the new EVA6400 and EVA8400 that were announced. If you're already familiar with the EVA and it's virtualizated pool of disk drives, you can skip down to my heading titled "What's New"?

The EVA was first announced in 2001. We've shipped nearly 70,000 EVAs and nearly half of that has been in the last few years. Why so many more over the recent past - because we've been able to substantiate the ease of use benefits of the EVA and with the growth of data, I think more and more customers understand that the EVA is the easiest mid-range array to manage in the industry.

So as a short primer for those of you that maybe don't understand EVA virtualization, I'll briefly summarize it here. At it's core, virtualization is a logical abstraction of the underlying physical widgets (whether your talking servers, storage, network, etc). With the EVA, we are virtualizing at the storage system level to hide the underlying physical disk drives so that what you manage is a pool of capacity. These pools of virtual capacity can be configured as virtual disks and presented to any or all connected hosts. The EVA capitalizes on virtualization to provide optimal performance, ease of management, improved capacity utilization, powerful data replication tools, and faster rebuild times, while simplifying the management of the virtualized storage capacity. There's a lot more that we could talk about here on the EVA's virtualization capabilities but for now, I'll point you to the white paper titled Storage virtualization and the HP StorageWorks Enterprise Virtual Array. It is a good resource to get you going on the EVA and virtualization.

What's New?

So that brings me to a discussion on what's new. There are two new EVA models - the EVA6400 and EVA8400. They join the EVA4400 that we announced about a year ago when we refreshed the low end of our portfolio; this announcement refreshes the rest of the EVA family.

Here's a summary of what's new:

Support for Vraid 6 providing double the parity of Vraid5 while providing the virtualizations benefits to grow and shrink the Vraid set. Vraid6 is unique to the EVA compared to traditional arrays that deliver only RAID6.
Increased maximum LUN size up to 22TB to support applications needing larger LUNs like Microsoft and Oracle and we have also increased the number of LUNs supported (NOTE: updated this as I had a typo here in the original post. The EVA8400 supports either 14TB or 22TB of cache)
Introducing 72GB solid state drives (SSD) to support high I/O low latency applications. The EVA supports up to 8 SSD's in an array.
The EVA8400 scales to 324 disks and 324TB while the EVA6400 scales to 216 drives and 216TB. With support for the same disk drive enclosure that's supported in the EVA4400, the new EVA's offer increased performance density---more performance in the same footprint
Increased cache up to 32GB for improved application read and write performance
Increased our snapshots from 16 to 64 for increased flexibility in data mining and restores

Here are a few things you can play with to learn more about the new EVAs. The first one is a very cool 3D interactive virtual product tour. This allows you to see a 3D view of the EVA, zoom in, turn it around and really "play" with what the EVA looks like. There are two of these 3D tours, one for the EVA6400 and one for the EVA8400. Here is also a Flash-based product demo that gives a high level picture of the new EVA models. The demo has a tab titled "see it in action" - this is a simple description of how virtualization in the EVA works. Check these out and let me know what you think.

One of the main benefits we highlighted in the announcement was that the EVA costs up to 50% less to manage than other competitive traditional disk arrays. I'll discuss this more in my next post.

Changing the economics of storage infrastructure with virtualization

CalvinZ — Wed, 11 Mar 2009 18:30:00 GMT

By Calvin Zito

Yesterday I talked about the announcement that our Technology Solutions Group did and briefly mentioned the part HP StorageWorks had in that announcement. Today, I'll drill down a bit more into the StorageWorks news.

The current economic conditions are affecting everyone but we all know that the information explosion that we've all been talking about for over a decade doesn't seem to care much about the economy. Many customers are attempting to take costs out to free up capital for their core business processes but the continued information explosion creates specific challenges for IT to efficiently store, protect, optimize and manage data. Adding to this, many data centers are not optimized for agility; a good portion of the IT budget is spent in maintenance and operations. IT is expected to help the business take advantage of opportunities that arise in this new economic era by reacting quickly to deliver new services that help drive growth. Really nothing new here, but I wanted to set the context.

We believe that the next generation data center is core to meeting these challenges. We call this the Adaptive Infrastructure. One of the core tenants of the Adaptive Infrastructure is helping customers move from their current state of high cost IT islands and siloed people resources to low cost pooled assets with more predictable service levels. Virtualization is key to that. Many customers have already virtualized their servers and as a result there's been improvements in utilization, service provisioning and disaster recovery/availability of those servers. If the rest of your infrastructure (e.g. storage, network, etc) isn't virtualized, then you still have limited flexibility. I just saw a post by my colleague in BladeSystem Jason Newton diving deeper on this topic and it's worth a read.

These virtual server environments have unique storage challenges around capacity management, storage provisioning, and data protection/management. And that gets me to the heart of what the announcement this week is about.

Our goal is to reduce the complexities and inhibitors of virtual server environments through the intelligent use of storage virtualization. We're making investments in this technology to optimize capacity, simplify storage provisioning and improve data management across virtual IT environments.

This week's announcement was focused on Fibre Channel storage networks. But we're not suggesting this is the answer for every application or customer environment. We have a very deep (and I know at times confusing) portfolio of products and solutions. But you really don't need an infrastructure vendor who only has a hammer because then every problem looks like a nail. You need an infrastructure vendor who has the breadth of portfolio to match the solution to your specific problem and data types at the lowest cost possible. So again, this announcement is focused on Fibre Channel based solutions - as we continue to integrate LeftHand Networks into our portfolio, we'll have more to say about storage virtualization with other storage networks (Shared SAS, iSCSI, etc.).

So that brings me to the news. There were three new or updated solutions we announced:

HP StorageWorks EVA6400 and EVA8400 virtual storage arrays helps customers save up to 50% in storage management costs for common storage administrative tasks compared to competitive traditional arrays
HP StorageWorks SAN Virtualization Services Platform (SVSP) can lower TCO by pooling and sharing of heterogeneous storage resources. You can improve your capacity utilization by 300% and manage 3X the storage capacity per administrator.
The new Data Protector 6.1 software combined with the EVA offers the industry's best (and we think only) replication based Zero Downtime Backup and recovery for VMware environments and is up to 70% less expensive than other enterprise backup products.

I'll go into more details over the next several days but let me leave you with a pointer to a video by our VP of Marketing, Stephan Schmitt. Stephan is at FOSE this week and was interviewed at the event just yesterday. This video is a nice overview of the announcement.

One last footnote I have to make as I can't wait until tomorrow's post where I'll drill down on the EVA6400 and EVA8400. One of our competitors has tried to make their pre-announcement of solid state drives a year ago as a proof point of their innovation. The funny thing is that we source those drives from the same OEM partner. This competitor had made bold and frankly ridiculous predictions that we would not have SSD drives until late this year or maybe in 2010. Well, I've got news for you Chuck - we have SSD drives in the EVA now and have had them in the XP Disk Array for a few months and in our BladeSystem for even longer.

Capacity discussion follow-up

CalvinZ — Fri, 19 Dec 2008 01:43:00 GMT

By Karl Dohm

Since Jim Haberkorn is off on vacation, I'd like to provide some continuity and add a few thoughts on the capacity discussion between Jim and Alex McDonald. See Jims's post presenting the case for NetApp capacity utilization problems and Alex's post on why Jim's post isn't to his liking. In this post I'd like to address some of Alex's criticisms and discuss real numbers.

It's no coincidence that capacity utilization is one of the most talked about aspects of NetApp storage. Competitors are not collaborating and reading from some anti-NetApp playbook. EMC and HP have reached similar conclusions on NetApp capacity utilization quite independently. If one simply considers the length of time that NetApp has been pushing back on this issue, and the sentiment they use to state their case, it shouldn't be much of a stretch to conclude that something may be amiss.

NetApp's approach to responding to the capacity utilization issue is consistent with its response to its other major issues: performance and usability. That is, create volumes of pro-NetApp information so that as the dust settles a case can be made to a confused audience that the problems don't exist. Consider the data put forth by NetApp and ask whether anyone independent could validate or truly make sense of the information. In fact I believe there is a pretty strong correlation between the quantity of written information produced by NetApp and the size of the problem its covering.

Instead of a bunch of esoteric capacity calculations, let's keep it simple with capacity utilization comparisons. It doesn't get simpler than taking two machines side by side and see what the customer gets for usable number of bytes after basic LUN provisioning. Anyone can perform this test. For now let's limit this comparison to basic array provisioning. That is, no thin provisioning, deduplication, reservations, snapshots, snapshot reserve, or any other thing to confuse the results. We can then add those items in one by one and discuss the tradeoffs that they bring.

Suppose you have two systems each with 54x 144GB spindles - a FAS2050 and an EVA4400. I chose 54 because it allows a simple to understand 25 spindle aggregate on both sides of the cluster. In the EVA these 54x spindles all can be placed in a single disk group yielding 5464 GB of usable capacity. This number and those that follow below include all deductions that take away from usable capacity - i.e. formatting, parity, sparing, metadata overhead, etc. By usable, I mean that a customer can write their production data on every one of those bytes, and those bytes are backed by RAID.

Consider the FAS2050. There are lots of ways to configure the FAS for 54x spindles, which leads into some interesting usability discussions, but I'll avoid that topic for now. Putting 25 in the a-side aggregate and 25 in the b-side aggregate, the remaining 4 of 54 spindles are used by global sparing, 2 per side. Usable capacity is shown by the FilerView GUI to be 4122 GB.

The EVA provides about 33% more usable capacity - these are bytes which can hold customer data. And if someone thinks 54 is a magic number, it's not important which total spindle count is chosen - the EVA always wins in this comparison by a substantial margin.

There is always a tie between NetApp capacity and performance, and a simple one I'll point out here is that in this configuration 4 of 54 spindles participate in no I/O whatsoever, and another 12 of 54 hold no customer data. If EVA can use all 54 spindles for I/O. and NetApp can use only 42 of 54, it's no wonder why the EVA has significant throughput advantages.

NetApp deduplication provides some relief for the FAS on this topic, or at least so NetApp would have you believe. But, there are issues with this technology. The scope of de-duplication on the 2050 is limited to a volume of size 1TB, meaning one has to deduplicate across isolated, relatively small pools. Additionally, throughput on a de-duplicated LUN drops to a fraction of its initial, already unimpressive value. And you may as well not even try to run load while the lengthy initial deduplication phase is happening, as you get a fraction of a fraction. Most customers will not trade off this kind of performance loss for the gain in virtual capacity. And beware, when the FAS runs out of space on its volumes, which can happen if you miscalculate your deduplicated space savings or your app unexpectedly shifts things around slightly, the LUN is taken offline automatically.

Configuration details

NetApp FAS2050 Configuration:

One 25 spindle aggregate per side of cluster (contains root volume)
Default 14+2 raid-dp raid groups in aggregates
54 total 146GB spindles
4 spares
5% free space overhead is assumed (unused space managed by the user) per volume and per aggregate.

Explanation for the 5%: This might be overly generous given this post on volume and aggregate free capacity, which hints at the need to leave up to 20% free space in both volumes and aggregates on the FAS. The referenced post isn't an exchange of NetApp bashers trading tall tales, it includes a real NetApp customer with severe performance problems and references to conflicting help from multiple NetApp sources, including Steve Daniel who describes his title as Director, Database Platform and Performance Technology, NetApp. Based on the entire exchange, it seems we should be using something more, up to perhaps 20% free in each.

That interpretation would make the NetApp numbers much worse. At 20% overhead in the aggregates and volumes, NetApp would give 2922GB usable capacity, meaning EVA provides 87% more usable space. Not sure what to believe based on the post on volume and aggregate fill capacity as it's unclear if these are best practices and under what condition these rules apply, but it clearly hints of some much bigger problems in the FAS given the right workload. This customer had problems that were validated by NetApp as possibly being caused by the fill level of volumes and aggregates. I think making the assumption that 5% has to be left free in each is being more than fair to NetApp.

Just in case NetApp removes the post on volume and aggregate fill capacity , I captured a small except below of what the customer had to say..

Please clear up something for me - we are getting conflicting messages from different NetApp people. We have severe performance problems and there are two theories:

1) We allowed the aggregate to exceed 80% capacity.
2) We allowed the main volume to exceed 80% capacity.

Both were, in fact, true. We have rectified both conditions, but the performance problem persists.

EVA4400 configuration:

Single 54x 146GB spindle disk group
Double sparing (4 total spares)
4+1 RAID-5

Making Sense of WAFL Part 4

CalvinZ — Thu, 04 Dec 2008 20:47:00 GMT

By Karl Dohm, HP Storage Architect

To recap, in this series of posts we are exploring some of the limitations of WAFL and specifically how those limitations manifest themselves to an average user of the FAS. For my previous posts see Part1, Part 2 , and Part 3.

I had made the assertion in the original post that some of the competitive disadvantages on the FAS involved throughput, capacity utilization, and ease of management. I had just started on the throughput part of the discussion when Konstantinos Roussos of NetApp posted that I was off the mark and cited the Avanade paper as one piece of evidence to prove it. So in the interest of fairness, I decided to try and understand what the Avanade paper was trying to say.

One of the initial tests described in the paper was rather simple to set up, and it was described by the experts at Avanade as one to "assess the overall performance of the FAS3050". I'm always looking for something relatively simple to set up that assesses the overall performance of an array, so this captured my interest. Since I didn't come up with the test, there shouldn't be any confusion that I somehow biased the selection to make NetApp look artificially unfavorable. Hopefully we can agree that this test has value, while not perfect, and has been arrived at in a fair manner.

My various recent blog posts have focused on trying to recreate the test result in the Avanade paper outside of the Avanade environment. The main purpose of this iteration, at least for me, is to arrive at some way to simply and fairly have a basis for comparison.

We still have some differences in how we run the tests, but for the most part these shouldn't matter much. Patrick's first and second post on the Avanade advisor blog describes some test details that augment the original Avanade paper. Here the test is run with 4Gb FC SAN connected to a 32 bit Windows 2003 Server on a physical machine. Patrick has evolved the test a bit as he is running on a 64 bit Windows 2008 Hyper-V virtual machine using the iSCSI stack. It's not practical to switch over to the environment he used, so I have to assume the differences are not significant to the outcome. I think there is some value though in minimizing variables and staying with a simpler stack between IOmeter and the LUN.

Everything else possible I can think of is being matched up, including spindle count of 20 in aggregate (root volume in different aggregate), raid group size of 20, rotational latency, raid type of LUN, IOmeter profile, IOmeter file size and so on. See the end of the post for more detailed configuration data.

Since the FAS3050 model used in the original test is no longer a current product, Patrick suggested using a FAS3070 or a FAS2050. It turns out that's good advice because, even with the new info, I could not get the 3050 results to come close to the Avanade results. I expected the same outcome on the FAS2050, but was in for a surprise.

It turns out that I get better throughput on the FAS2050 than Patrick did. For those of you thinking I'm spinning data, please open your minds and read this carefully.

For the LUN with no fragmentation, in our environment the FAS 2050 runs at about 4860 IOPs and 53 MB/s, which are average values taken over the first 20 minutes after full reallocation. Patrick's results maxed out at about 3460 IOPs and 39MB/s - which he said was also against the LUN with no fragmentation. My result was nearly 40% faster. So if you took that data by itself, this would be a great endorsement of the FAS by a competitor.

But there is more to the story of course. This is a random workload, and as the LUN fragments the throughput degrades. I ran 14x 20 minute segments of this load (about 4.5 hours) after an initial reallocate and the results for the FAS2050 are shown below.

20 min segment	IOps	MBps	Avg Resp Time
1	4864	52.7	30.8
2	4494	48.6	33.4
3	4296	46.5	34.9
4	4141	44.8	36.2
5	4014	43.4	37.3
6	3896	42.2	38.5
7	3812	41.2	39.3
8	3714	40.2	40.4
9	3676	39.8	40.8
10	3616	39.1	41.5
11	3576	38.7	41.9
12	3533	38.2	42.4
13	3499	37.9	42.9
14	3449	37.3	43.5

The results Patrick reported were closer to where the FAS ended up after fragmentation took its toll. So I'm guessing he may have not reallocated his volume in between each IOmeter run, meaning the LUN was in fact fragmented when he got to the higher thread counts. Anyway, his data matches nearly perfectly with my post-fragmentation data in the 14^th segment: 3460 IOPs at Avanade vs 3450 here.

Note that I ran 150 threads in a single IOmeter worker, which was what it took to get an approximate 30msec average response time at the start of the test. The 30msec average figure is somewhat standard to use in the industry.

Let's compare these results to the EVA4400. My understanding is that these two arrays (FAS2050 and EVA4400) are often sold against each other in competitive situations, so it makes sense to see which array has an edge.

The EVA4400 runs this same test with a throughput of nearly 6000 IOPs and 64MB/s, which doesn't degrade over the course of the 14x 20 minute segments. The EVA LUN doesn't fragment, so the throughput remains roughly the same in each 20 minute segment.

Summarizing, the FAS LUN throughput is 81% of the EVA LUN when it is not fragmented and 58% of the throughput when it is fragmented. Since the FAS LUN can't avoid fragmenting with this load, the 58% figure is the more relevant one for a typical situation. Note that the FAS LUN has not yet settled to a steady state after these 14 segments, so its numbers will be somewhat lower if this test runs longer.

Ok, that's a lot to digest, and given the outcome there will certainly be criticisms. But, it's a relatively simple test that can be recreated by anyone out there; it's a test that I didn't choose; the test is said by a Windows integration expert to be a measure of overall array performance, and its pretty clear that there is an EVA advantage.

By the way, in case it's thought that the EVA just got lucky with this choice of test, I'm open to trying any other IOmeter access specification that anyone wants to run, as long as the test is at least somewhat relevant to customer workloads and stays reasonably simple to set up and understand.

Finally, it deserves mentioning that this thread has a tie to the associated topic of cost and capacity utilization. This is mostly a topic for another day, but the EVA can be deployed without any additional spindles over the 20 used in this test. The FAS, if running in a cluster (which is redundancy comparable to EVA) would need at least one additional global spare spindle on the a side of the cluster, three additional spindles to hold the root volume of the b side of the cluster, and one global spare for the b side of the cluster. That's an overhead of five additional spindles to support an array with 20 data spindles.

You may be able to sense where I'm going with this. Five spindles incur roughly an additional $5000 in purchase price for the drives alone, and with those five you would need additional drive shelves, cabling, rack space, power, and cooling. Not sure how many dollars that all that adds up to, but some would call that a significant additional cost burden for an array that provides 58% of the throughput.

Additional configuration details for runs done here

FAS2050

20 spindle aggregate containing 1x 1TB volume
1TB volume containing 1x 1TB LUN
2 front end FC ports per FAS filer
150 threads in IOmeter (~30mseg response time at start of test)
MPIO policy round robin
Ontap 7.2.4L1

EVA4400

20 spindle disk group containing 1x 500GB LUN
170 threads in IOmeter (~30 msec response time)
2 front end FC ports per controller
09004000 firmware

Common

15K 144GB drives
IOmeter writes to a 100GB file placed in the lowest LBAs of the LUN
IOmeter access specification as in Avanade post
Emulex dual ported HBA
Emulex Queue depth = 254, Queue target=0
Windows 2003 32 bit server
MPIO and vendor specific DSM - SQST for EVA and RR for FAS
4GB FC SAN
Proliant DL380-G4

Making sense of WAFL – Part 3

CalvinZ — Sat, 22 Nov 2008 05:03:00 GMT

By Karl Dohm, HP Storage Architect

Sorry for the delay, I'm just finally getting back to this making the third installment on this thread. For the previous posts see threads Making Sense of WAFL and Making Sense of WAFL Part 2. In this series it we are trying to seek technical truths in the highly varying posts about NetApp performance, capacity utilization, and usability.

I want to thank Patrick for his post as it was very beneficial in helping to figure out how the Avanade tests were run. Clearly these tests were run with careful attention to detail.

As I said previously, I do like the notion of doing IOMeter based throughput tests to compare arrays. Relatively speaking it is simple to configure, there is little ambiguity, anyone out there who is listening can repeat the test, and it offers us a fair opportunity to compare various arrays in an apples to apples fashion. IOMeter can be modified to push nearly any load we like, so if someone has a favorite workload we can focus on whatever flavor of load we like. Most other approaches are a bit too loose for me, leaving too much room for interpretation and variations.

Patrick mentions the true test, i.e. that there are many happy NetApp customers who are running Exchange. There is truth to this of course, but it isn't a good basis of comparison because every major array vendor has happy Exchange customers. However, its reasonable to say that these installations can't know what they don't know.

I'm not saying you can't run Exchange successfully with NetApp. In fact I'm sure you can. The question looking for an answer is whether the user gets good value in choosing NetApp to run Exchange. Are they perhaps buying more iron than they need in order to handle their workload? So if its ok with everyone, lets stick with simple IOMeter to probe this further and keep things from getting too hazy.

Unfortunately I don't have access to a FAS3070, so I reran the test as described by Patrick on a FAS3050c. My numbers for 128 threads came in at 25.5 MB/s and 2950 IOPs with an average response time 43msec - on a completely defragmented LUN (best possible state). This is still a long way off from the Avanade reported results of 48.1 MB/s with an average response time of 29.1 msec on a fragmented LUN.

Rather than comparing this result to our entry level EVA again, I'll just make an assumption that I've done something wrong. So, please help me further iterate in understanding what it takes to achieve the results as reported in the paper.

One interesting clue is that Patrick mentioned was that MPIO was not used in the test. I find this to be unexpected as this either means that all the load was run down a single 2Gb FC path to the FAS, or IOMeter was somehow configured to drive load down multiple paths to the same LUN, or some other multipathing product was used. Given the heavy, random nature of the load, I would have expected the use of multiple paths just in case the host port became a bottleneck. Perhaps this disconnect triggers figuring out what is different in the environment.

Here is some more config info. I'm using a Proliant DL380-G5 running Windows Server 2003 with Emulex 4Gb/s dual ported HBA through 4Gb Brocade switches. The Emulex max queue depth is set wide open to 254. I am using MPIO RR to give the FAS the benefit of having multiple paths share the load. Ontap is 7.2.2.