Great FREE tool for VM file system alignment

November 7, 2011 Leave a comment

This is big IMO. One of the “vSpecialists” at EMC (a technical team in the field that focuses on evangelizing EMC-VMware integration) has just released a FREE tool that can correct file system alignment in your VMware environment.  Note: The tool is not limited to just EMC customers.

File system alignment is a problem that exists for many folks. It lurks in the background causing excessive disk I/O on the arrays of those who are unbeknownst to its existence. In smaller shops, it may not be a huge deal if you’re not pushing a lot of IOPS, although I would still recommend doing it just to avoid performance challenges later.

An excerpt from the announcement:

“The idea of creating this came from the lack of a decent free alignment tool out there for VMware admins. Most every other one at there was either something you had to purchase or you had to be a customer of the vender to get access to it. And even after getting access these tools were either (in my opinion) limited in what they did, how they did it, or had become obsolete in a console-less vSphere 5 architecture.

For those they don’t know, alignment with Virtual Machine disks on top of Storage Arrays has been a performance issue for a long time. I won’t go into long detail explaining the problem or the benefits to alignment. There are great posts by Duncan ( and Kevin( on what the issues are and some of the tools available.”

Get a copy of the tool here:

Categories: Uncategorized

A new true Unified storage contender in the market

October 13, 2011 1 comment

Most folks have heard of Unified storage by now and are well aware of the basic capabilities, namely NAS and SAN in a single box.   NetApp and EMC have been the primary players in this market for some time, and to date have been the only vendors to offer a true Unified solution in the enterprise arena.  In using the term “true Unified”, I’m looking at the technology and determining if it is leveraging a purpose-built storage OS to handle SAN and NAS data delivery to hosts.    There are other vendors out there claiming they have Unified capabilities because it is a compelling feature for customers, but by my definition taking a SAN and throwing on a Windows Storage Server to do CIFS does not count as a true Unified solution.   I’m less concerned about the semantics of whether or not there are truly two code bases in the box, one serving SAN and the other serving NAS, as long as they operate from a common storage pool and have a single-point of management.  


I figured the next vendor with a true Unified solution would be Dell, as multiple signs have been pointing to them integrating some NAS technology they acquired into their existing SAN platforms (Compellent and Equalogic), but surprisingly, the announcement yesterday came from IBM.   IBM took the V7000 array they released last year based on SVC technology and added Unified functionality to it by leveraging their SONAS product (Scale-out NAS).    I consider this to be a pretty major announcement, as NetApp and EMC can no longer claim superiority as the only Unified storage vendors with native solutions.   IBM could sell OEM’d NetApp arrays (N-Series) in the past if the situation warranted, and it will be interesting to see if this announcement is the beginning of the end for the IBM-NTAP OEM relationship.


In the case of the V7000, IBM has integrated the SONAS code into the solution and made one GUI to manage it.   Because the V7000 runs SVC-based code and the NAS is handled by SONAS components, it does not appear to be a unified code-base like NetApp, but two code-bases tied together with a single GUI like the VNX.    From a picture I saw on Tony Pearson’s blog, they are including two IBM servers in the stack (called “File Modules” that are akin to datamovers or Filers) that run active-active sitting in front of the V7000 controllers.  


I had some exposure to SONAS when I worked at a large pharma and saw its development first-hand for a project we undertook but never bought.   IBM hired the guy who created SAMBA (Andrew  Tridgell) to architect an active-active clustered SAMBA architecture to run on top of IBM’s Global Parallel File System (GPFS).   It was a very interesting system, and Andrew Tridgell still ranks as one of the smartest people I have ever met, but back in 2007-2008 it was just a little too new.   Fast forward 3 years and I’m sure the system is much more robust and fully-baked, though I’m not 100% sold on using SAMBA for CIFS access in the enterprise.


Because SONAS/GPFS is a scale-out system, the NAS functionality in the V7000 does have an advantage over EMC and Netapp in that the same file system can be served out of the two File Modules simultaneously.  However, it appears the V7000 may be limited to just two file modules from what I see, unlike a full SONAS/GPFS solution or something like Isilon.


Only time will tell if the V7000 Unified will be successful and IBM will keep development of the product a hot-priority.   Some folks would point to the legacy DS boxes as an example of a technology that was good when it was first released, but then sat for years without any major updates while the technology continued to evolve.   But at least for the immediate future, the V7000 is certainly worthy competition in the Unified space and an example of how competition is good for the industry overall, as it forces the big gorillas to keep on their toes and continue to find new ways to innovate.  


Further reading:

Categories: IBM, NAS, SAN

De-duplication just got cheaper

October 11, 2011 Leave a comment

A week ago I wrote that the high cost of data de-duplication and the lack of downward movement on prices was a potential concern for the market players. I have seen two recent cases (and heard first-hand of more) where customers were seriously considering B2D on 2 or 3TB NL-SAS drives without de-dupe as they were finding it to be a cheaper acquisition.

Coincidentally, EMC responded this week by announcing a refresh of the low-end DD platforms, giving quite a lot more capacity with a much lower price point. The DD160 replaces the 140, 620 replaces 610, and 640 replaces 630. The cost of the existing DD670 was also reduced. I think this is a smart move by EMC and will make them much more competitive at the low-end, where customers would often choose an inferior technology simply because of price point and meeting “good enough” criteria.

A common scenario I found was most small-medium sized companies have at least 10TB of backup data. In the DD product line, this would put them above the previous low-end models and into the higher-end 670, making it out of reach for them financially.

What I’m seeing is the new DD640 with expansion shelf capabilities nicely solves this problem. It can scale to 32TB usable pre-deduped capacity. I just ran a sample config comparing a 670 with a 32TB shelf to a 640 with 30TB shelf and the cost is cheaper by tens of thousands. Kudos to EMC on this one. Now, if they could only do something for Avamar cost of entry at the low-end of the market…

Categories: Backup, De-dupe, EMC

The Cost of Data De-duplication

October 6, 2011 Leave a comment

Backup data-deduplication has been one of the hottest technologies of the last few years.   We’ve seen major players like EMC spend 2 billion to purchase DataDomain, and the industry in general is a 2 billion dollar market annually.   Why all the focus here?  Two reasons I believe:

1) These technologies solve an important business need to back up an ever-increasing volume of data (much of it redundant). 

2) Storage manufacturers have to find a way to maintain their growth rates to satisfy Wall St. and backup de-duplication is still one of the fastest areas of growth.

I was shocked to hear the other day when a very large client reported they were moving away from backup de-duplication and simply going to backup on SATA/NL-SAS 3TB drives.   What was the reasoning behind that decision?   The cost of SATA/NL-SAS drives is coming down faster than the cost of data de-duplication.  

That is certainly an interesting theory, and one that deserves some further consideration.  If there is a common challenge I’ve seen with customers, it’s dealing with the cost associated with next-generation backup, and prices have only come down minimally in the past 2 years.   Backup is still an oft-forgotten step-child within IT infrastructure and it’s hard to explain to corporate management why money is needed to fix backups.   Often, when I’m designing a storage and backup solution for a customer, the storage is no longer the most expensive piece of the solution.   Thanks to storage arrays being built on industry-standard x86 hardware, iSCSI taking away market share from Fibre Channel, and advancements in SAS making it the preferred back-end architecture instead of FC, the storage has become downright cheap and backup is the most costly part of the solution.   This issue affects the cost-conscious low-end of the market more than anywhere else, but nonetheless it can be a challenge across all segments.  

In the case of this particular customer who decided it was more economical to move away from de-dupe, there is certainly more to the story.   Namely, they were backing up a large amount of images and only seeing 3:1 de-dupe ratios.    However, I have recently seen another use case for a customer who only needed to keep backups for 1 week where it was more economical to do straight B2D on fat SATA/NL-SAS solution.  By layering in some software that does compression yielding 2:1 savings, it becomes even more economical.   

From the manufacturer perspective, I’m sure it’s not easy to come up with pricing for de-dupe Purpose Built Backup Appliances (PBBAs).   The box can’t be priced based on the actual amount of SATA/NL-SAS in the box as that would be too cheap based on the amount of data you can truly store on it, but it can’t priced for the full logical capacity as there less incentive to use a de-dupe PBBA vs. straight disk.   Generally speaking, to make a de-dupe PBBA a good value, you need to have a data retention schedule that can yield at least 4:1 or 5:1 de-dupe in my experience.   

Even if you can’t obtain 5:1 or greater de-dupe, there are a few additional things worth considering that may still make a PBBA the right choice instead of straight disk.   First, a PBBA with de-dupe can still offer a lot of benefits for bandwidth-friendly replication to a remote site.    Second, a PBBA with de-dupe can offer a significantly better environmental savings in terms of space, power, and cooling than straight disk.   

Categories: Backup, De-dupe

The Importance of Storage Performance Benchmarks

September 15, 2011 2 comments

As one who scans the daily flood of storage news every day, I’ve started to notice an uptick in the number of articles and press releases over the past year highlighting various vendors who have “blown away” a benchmark score of some sort and claim ultimate superiority in the storage world. 2 weeks later, another vendor is trumping that they’ve beaten the score that was just posted 2 weeks prior. With the numbers we’re seeing touted, I’m sure 1 bazillion IOPS must only be right around the corner.

Most vendors who utilize benchmarks tend to be storage startups, looking to get some publicity for themselves, not that there’s anything wrong with that. You gotta get your name out there somehow. For the longest time, the dominant player in the storage world, EMC, refused to participate in benchmarks saying they were not realistic of real-world performance. I don’t disagree with that, in many cases benchmarks are not indicative of real-world performance. Nevertheless, now even EMC has jumped into the fray. Perhaps they decided that not participating costs more in negative press than it does good.

What does it all mean for you? Here are a couple things to consider:

  1. Most benchmark tests are not indicative of real-world results. If you want to use a benchmark stat to get a better sense of what the max system limits are, that’s fine. But, don’t forget what your requirements truly are and measure each system against that. In most cases, customers are using a storage array for mixed workloads from a variety of business apps for a variety of use cases (database, email, file, and VMware, etc).  These different applications all have different I/O patterns.  The benchmark tests don’t simulate workloads that are related to this “real-world” mixed I/O pattern.   Benchmarks are heavily tilted in favor of niche use cases with very specific workloads. I’m sure there are niche use cases out there where the benchmarks do matter, but for 95% of storage buyers, they don’t matter. The bottom line is be sure the system has enough bandwidth and spindles to handle your real MB/sec and IOPS requirements. Designing that properly will be much more beneficial to you than getting an array that recently did 1 million IOPS in a benchmark test.
  1. Every vendor will reference a benchmark that works in their favor. Every vendor pretty much seems to be able to pull a benchmark stat out of their hat that favors their systems above all others.

Here’s an example I saw last year when working with a customer who evaluated 3 different vendors (IBM, NetApp, and EMC), and how I helped the customer get clear on what was real. In this case, both non-EMC vendors were referencing SPC numbers that showed how badly an EMC CX3-40 performed relative to their platforms. A couple alarms went off for me immediately:

  1. The CX3-40 was a generation old relative to the other platforms. The CX4 was the current platform on the market (now replaced by VNX). In other words, not an apples-to-apples comparison.
  2. At the time the CX3-40 existed, EMC did not participate in SAN benchmarks for its mid-range or high-end arrays.

I took a look at the V7000 SPC-1 benchmark and found some interesting conclusions.  Here is a chart that shows how the V7000 performed on the benchmark, and it shows other competitors as well:

The V7000 scored 56,500.   Interesting to note, since the box only supported 120 drives at the time, they had to utilize the SVC code in it to add on a DS5020 box, which allowed them to add more drives (200 total) to the configuration.  They put 80 15K RPM drives in the DS5020, higher speed drives the V7000 didn’t support natively at the time.    What’s important to note about the CX3-40 results seen in the SPC1 results is that this was a CX3-40 that NetApp purchased and ran a test on, then submitted the results to without EMC’s permission.  I don’t care what your vendor affiliation is, that’s not a fair fight. EMC had no input into how the array was configured and tuned.    Even though the array could hold 240 drives, it was only configured it for 155.    The CX3-40 scored 25,000.   Let’s make a realistic assumption that if EMC had configured the array and tuned it for the benchmark as other vendors did, then it could have done at least 25% better.   This would give it a score of 31,000.    The CX3-40 was a predecessor to the CX4-240 and they both hold 240 drives.   Performance and spec limits pretty much doubled across the board from CX3 to CX4, because EMC implemented a 64-bit architecture with the CX4’s release in 2008. So, again let’s make a realistic assumption and take the 31,000 result of the CX3-40 and double it to create a theoretical score for the CX4-240 of 62,000.

If I look at other arrays that are comparable to the CX4-240 in the results list, such as the DS5300 or FAS 3000 series, this theoretical score is right in the ballpark of the other arrays.     I would hope most would agree that this shows all the arrays in-scope were within striking distance of each other.   What exactly do these numbers mean relative to your business….not much. You can’t design a system for your business needs using these numbers. When most customers are analyzing their performance requirements, they have figures for IOPS, throughput, and latency that they need to meet to ensure good business application performance, not a theoretical benchmark score target.

Benchmarks can certainly be interesting, and I admit sometimes I think it’s cool to see a system that did X number of GB’s per second of throughput or X million IOPS, but my recommendation is don’t get to spun up on them in your search for a storage platform.  Every vendor has a benchmark that makes them look the best.  Instead, use your own metrics or work with a trusted business partner who can help you gather the data specific to your environment and evaluate each technology against how well it meets your business needs.

Categories: EMC, NAS, NetApp, SAN

Your source for vSphere 5 updates…

July 13, 2011 Leave a comment

vSphere 5 was announced yesterday and will be GA in the not too distant future.   My colleague Dave Lawrence, the virtualization practice director at RoundTower Technologies and a former VMware SE, runs the popular blog.   He’s currently posting lots of updates summarzing all the new features you need to know about.   I highly recommend that any VMware and Storage admin go check it out as there are lots of changes in vSphere 5 that can affect both worlds.

Here’s the link to send you straight there:

Also be sure to follow him on Twitter at

The Hoosier Storage Guy will go dark as I head out on vacation for a while.   Enjoy your summer everyone!

Categories: Uncategorized

Another real example of snaps vs. backups

June 22, 2011 Leave a comment

StorageZilla, who normally has a heavy EMC bias, has a post up today that gives a great example of why you need a backup solution in addition to snapshots. No vendor bashing or obsessive promotion here, simply a good example of what can happen if you don’t have a purpose-built backup system.

Check it out here:

For more examples of why most folks continue to look at a purpose-built backup solution, see my original article on the topic here:

Categories: Uncategorized Tags: ,

Does Primary Storage De-Dupe Save You Money?

May 31, 2011 Leave a comment

A few months ago I was in a discussion with a customer that I thought was worth sharing. It centered on primary storage de-duplication vs. automated storage tiering. Excluding backup de-duplication, de-dupe has also been a topic attracting a lot of attention as a feature for SAN storage. NetApp focuses heavily on this feature in their storage products (for both NAS and SAN). EMC has been a bit behind in this regard, only having de-dupe/compression for NAS originally and more recently including compression with their SAN block storage offerings. Media outlets such as The Register have published articles indicating that EMC executives have hinted block deduplication is on the roadmap for their storage arrays. Outside of NetApp and EMC, no other major storage vendors have introduced similar functionality into their product line, but several are rumored to be in the works.

What De-Dupe Options Exist Today?

Currently, EMC does single-instance storage and compression on file system (NAS) data, and on block (SAN) data it does compression. The de-dupe and compression can be applied to the entire datastore or individual VM’s.   You cannot de-dupe or compress individual VM’s on a Clariion or block-only VNX using Fibre Channel/iSCSI storage. This is similar in the NetApp world. If you run VMware on NFS, de-dupe can be done per VM. With FC or iSCSI, de-dupe applies to the entire datastore.    In a block environment using VMFS file systems where you have a variety of VM’s that need different performance levels, you would probably want to consider multiple datastores setup on different storage tiers. One might be for higher-performing production VM’s and would not have de-dupe/compression enabled. You would create another Tier2 datastore for non-prod VM’s or VM’s that are often idle. This method of tiering is obviously a manual process that requires administrator involvement to re-balance resources.    Regardless of what any manufacturer will claim, de-dupe is generally not a technology that you want to enable on ALL of your primary storage. Compression and de-duplication is still best suited for infrequently accessed data or a low-performance environment, however many small to medium environments might fall under this classification so de-duping everything could be a possibility.

De-dupe vs. Automated Storage Tiering (AST)

At the end of the day, features are nice but the more important question is whether it truly saves you money and helps you be more efficient. In my discussion with the customer, we were discussing strategies to save space and improve the economies of storage. Naturally, this led us to discuss de-duplication and it also led us to a discussion comparing the savings of de-dupe to the savings from AST. Compellent introduced sub-LUN AST a few years ago and EMC introduced it in their product line in Q3 of 2010. Generally speaking, the typical performance profile of a customer array shows that the vast majority of LUNs are accessed infrequently. When zooming in to look at a busy LUN, again the performance profile usually shows that only a minority of blocks comprising that LUN are actually busy, while the rest of the blocks within the LUN are infrequently accessed. With sub-LUN AST, the hot blocks get moved up to SSD or 15K drives, while the majority of data that is infrequently accessed resides on SATA.

What I’ve found is using AST at the sub-LUN level with large amounts of SATA gives you better savings without the risk of overhead that can reduce performance when you introduce de-dupe or compression.  The caveat being the array must be properly designed so that there is enough SSD or 15K spindles to accommodate the hot blocks.  If the data has higher I/O characteristics so that it’s not a good fit for SATA, then it’s probably not a good fit for de-dupe or compression either because of the performance penalty you’re going to incur, hence there’s no savings either way.

As a theoretical example, let’s say we’re dealing with an environment that has VM’s living on 1TB SATA drives configured in a 5+1 R5 setup.   That yields 4500GB of usable space. A ballpark street price for an upgrade of 6 1TB drives equates to a cost per GB of $1.77/GB.   If there are 2TB’s worth of VM’s sitting out there, and they can be crunched down by 20% to save 400GB, it’s a savings of just $708.  Some vendors might complain that’s too low of an estimate on the savings, so let’s double it to 40%, now you’re saving $1416. On enterprise-class storage arrays that is not a significant savings, it’s more like a rounding error. Are you saving money? Sure. But I would have to wonder why even create the additional overhead for a savings like that.

Let’s look at a use-case for 2TB’s of VM’s residing on more expensive FC storage. I’ll use a cost per GB of $6. With 2TB’s of VM’s stored on that tier, de-duping to save 20% yields a cost savings of $2400. That’s certainly better than $708 but nothing to get overly excited about. Now, if I can move 85% of what’s on the $6/GB storage to $1.77/GB storage by using auto-tiering, my savings are about $9,000.

What’s the bottom line?

In the case of a large environment that has mostly expensive FC disk with data not requiring the performance characteristics of that tier, then perhaps that creates a compelling cost savings to implement de-dupe or compression, especially if you’re not able to implement AST because you’re on an older-generation platform that doesn’t support it. However, those older-generation platforms typically won’t support de-dupe either, because naturally vendors want to put all the flashy new features in the latest generation boxes. There are gateway devices you could put in front of your old storage to give you new features, but there are a variety of pro’s and con’s to consider with that best suited for another discussion . Certainly, de-duplication on primary storage can save you money. However, given all the hype that surrounds this topic, the savings aren’t necessarily what you might think they would be.


Categories: Uncategorized

Update on FCoE: The Current State of Real World Deployments

May 27, 2011 Leave a comment

FCoE has been out in the marketplace now for approximately two years and I thought it’d be good to discuss what we’re seeing in the real world regarding deployment.


For those not familiar with Fibre Channel over Ethernet (FCoE), it is being hailed as a key new technology that is a first step towards consolidation of the Fibre Channel storage networks and Ethernet data networks. This has several benefits including simplified network management, elimination of redundant cabling, switches, etc., as well as reduced power and heat requirements. Performance over the Ethernet network is similar to a traditional Fibre Channel network, because the 10Gb connection is “lossless”. Essentially, FCoE encapsulates FC frames in Ethernet packets and uses Ethernet instead of Fibre Channel links. Underneath it all, it is still Fibre Channel. Storage management is done in a very similar manner to traditional FC interfaces.


Across the R0undTower customer base in the Ohio Valley, adoption is still relatively low. I would attribute this to the fact that many customers in the Ohio Valley have found that traditional 1GbE iSCSI bandwidth will suffice for their environment. They never had a need to implement Fibre Channel, hence, there is little need to move to a FCoE environment. The most common FCoE switch is the Nexus 5000. Although some customers may not implement FCoE, we are seeing significant adoption of the Nexus line, with the 5000 often being used as a straight 10GbE switch. Even for medium-sized businesses that haven’t seen a need to adopt 10GbE, the drive to virtualize more will require greater network aggregate bandwidth at the ESX server, making 10GbE a legitimate play. In this case, the customer can simply continue to run iSCSI or NFS over this 10GbE connection, without implementing FCoE.

NFS and iSCSI are great, but there’s no getting away from the fact that they depend on TCP retransmission mechanics. This is a problem in larger environments, which is why Fibre Channel has continued to remain a very viable technology. The higher you go in the network protocol stack, the longer the latencies that occur in various operations. This can mean seconds, and normally many tens of seconds for state/loss of connection. EMC, NetApp, and VMware recommend that timeouts for NFS and iSCSI datastores be set to at least 60 seconds. FCoE expects most transmission loss handling to be done at the Ethernet layer, for lossless congestion handling and legacy CRC mechanisms for line errors. This means link state sensitivity is in the millisecond or even microsecond range. This is an important difference that ultimately is behind why iSCSI didn’t displace Fibre Channel in larger environments.

Until recently, storage arrays were not supporting native FCoE connectivity. NetApp was first to market with FCoE support, though there were some caveats and the technology was “Gen 1”, which most folks prefer to avoid in production environments. Native FCoE attach also did not support a multi-hop environment. FCoE has been ratified as a standard now, some of the minor “gotchas” have been taken care of with firmware updates, and EMC has also released UltraFlex modules for the CX/NS line that allow you to natively attach your array to a FCoE enabled switch. These capabilities will most certainly accelerate the deployement of more FCoE.

At the host-level, early versions of the Converged Network Adapter (CNA) were actually two separate chipsets included on a single PCI card. This was a duct-tape and bailing wire way to get host support for FCoE out to the market quickly. Now, Gen2 CNA’s are hitting the market, which are based upon a single-chipset. FCoE on the motherboard is also coming in the not-too-distant future, and these developments will also contribute to accelerated adoption of FCoE.


The best use case for FCoE is still for customers who are building a completely new data center, or refreshing their entire data center network. I would go so far as to say it is a no-brainer to deploy 10GbE infrastructure in these situations. For customers with bandwidth exceeding 60MB/sec, it will most certainly make sense to leverage FCoE functionality. With a 10GbE infrastructure in place already, the uplift to implement FCoE should be relatively minimal. One important caveat to consider before implementing a converged infrastructure is to have organization discussions about management responsibility of the switch infrastructure. This will particularly apply to environments where the network team is separate from the storage team. Policies and procedures will have to be put in place for one group to manage the device, or create ACL’s and a rights-delegation structure that allow the LAN team to manage LAN traffic and the storage team to manage SAN traffic over the same wire.

The above option is a great use-case, but it still involves a fair amount of pieces and parts despite being streamlined as compared to an environment where LAN and SAN were completely separate. Another use case for implementing FCoE today that is incredibly simple and streamlined is to make it part of a server refresh. The Cisco UCS B-series blade-chassis offers some impressive advantages over other blade options, and FCoE is built right in. This allows the management and cabling setup of the Cisco UCS to be much cleaner as compared to other blade chassis options. With FCoE already being part of the UCS chassis right out of the box, there is relatively little infrastructure changes required in the environment, management is handled from the same management GUI as the blade chassis, and there is no need to do any cabling other than perhaps add a FC uplink to an existing FC SAN environment if one exists.

Categories: Cisco, SAN

EMC VNX Goodies Sprouting Up this Spring

May 11, 2011 Leave a comment

Back in January when EMC announced the VNX platform, I wrote a brief blog post for those customers who had purchased a CX4 in the 2nd half of 2010 ( At the time, I advised that although the VNX is certainly an impressive platform, there’s no reason to fret about what you purchased. Here’s a recap of that post:

  1. The first batch of VNX didn’t ship until the end of January and supplies were tight and it takes time to implement an array after ordering (4-6 weeks). Therefore, most folks would have had trouble meeting go-live deadlines if they waited for something that hadn’t even been announced.
  2. The CX4 and NS platform will remain a viable shipping platform well into 2011 (that’s still the case).
  3. The CX4 was built on a long-standing architecture that is proven and reliable. While there’s been no indication of too many VNX Gen1 troubles, if you can’t take a chance with the first batch out the door, better to stick with the proven workhorse.
  4. VNX was based on the same software enhancements released in late 2010 on the CX4 in FLARE 30 and DART 6.0 on NS platforms.
  5. No need to worry about FC drive supply running out – they’ll be around for a long time.

What EMC announced today at Day 2 of EMC World gives us some insight into new enhancements coming for the VNX platform, and although it wasn’t explicitly stated, it’s safe to assume many enhancements going forward won’t be showing up on the CX4 or NS platform. Here they are (with greater detail available from Chad Sakac’s blog:

  1. High-bandwidth array. It appears this is an I/O module update giving you more 4-lane 6Gb/sec SAS backend ports.
  2. 2U 25 slot 2.5″ Disk Array Enclosures (DAE’s). These supported 10K drives only but now will support SSD’s including cheaper MLC flash (this will be great for increasing Flash adoption and we’ll probably see multiple tiers of Flash SLC and MLC within the same box).
  3. High-density DAE (60 slots). This requires a special high-density rack. There is a CX4 option available for this as well, though not quite as dense.
  4. Easy-to-use Appliction Provisioning Wizards from the customized VNXe version of Unisphere will now be included in the full VNX version of Unisphere. Curious to see if these make their way back to FLARE30/DART 6 Unisphere 1.0 systems. I could see this being important for smaller VNX5300 customers that needed a bit more oomph than what VNXe could offer, but the admins wear a lot of hats and don’t have time to be a full-time SAN admin.
  5. Cloud Tiering Appliance for VNX Networked File Systems. This looks akin to the old Rainfinity FMA, but instead of tiering to SATA or Centera, you tier out to a Cloud storage provider.
  6. Google Search Appliance integration with VNX NAS file systems.
  7. Full Replication Manager integration into Unisphere. I’m also curious to see if this will be retro-active for CX4 customers.

Are any of these absolute must-have’s for the average customer? Not really, although I’m sure they are must-haves for certain niches. So, while these are some goodies that will primarily be for VNX customers only with exceptions, there’s still no reason to fret that you missed out on anything big when you purchased a CX/NS last year.

Now, what I’m really waiting for and I’m sure several other folks are as well is a reduced “chunk” size for FAST VP auto-tiering. Currently, the tiering is done based on 1GB chunks, which will hopefully be cut-down significantly for greater efficiency. The other key capability will be mixed RAID types in the same storage pool. This will eliminate the need for customers to create a separate pool for logs on RAID 1/0, while everything else sits on RAID5. Another use-case that needs to be fixed is for a customer who wants a pool based on RAID 5, but is utilizing 2TB high-capacity drives for tiering that typically are recommended to be used with RAID 6 protection. The smaller your auto-tiering chunk, the more meta-data there is to keep track of in the system. Therefore, I would theorize this enhancement will only appear on VNX (should it ever appear), specifically because of increased CPU and RAM available on that platform.

Categories: EMC