Archive

Archive for the ‘EMC’ Category

Strategies for SRM with a VNXe

June 18, 2012 1 comment

Give credit where credit is due, EMC does a lot of things well.   VMware Site Recovery Manager (SRM) support for the VNXe is definitely not one of those.   EMC has done such a great job turning the ship around when it comes to VMware integration with their products thanks to guys like Chad Sakac (@sakacc), that it is beyond mind-boggling to me as to why it is taking such a long time to get this straightened out on the VNXe.  

Originally, it was stated that VNXe would support SRM when SRM 5.0 came out (Q3 2011), at least with NFS and iSCSI would be later down the road.  Then, the date slipped to Q4 2011, and again to Q1 2012, and again to Q3 2012, and I just saw an update on the EMC community forums where it’s now stated as Q4 2012 (https://community.emc.com/thread/127434).   Let me be clear to EMC and their engineering group, this is not acceptable.    Customers who have bought this product with the intent to move to fully replicated vSphere environments have a right to be pissed.   Partners who are responsible for designing best-in-class high-availability solutions for their SMB customers have a right to be pissed.   We don’t have unreasonable expectations or unrealistic high demands.   EMC just screwed this one up badly.

What I find most incomprehensible of all is the fact that the VNXe software is largely based on the underpinnings of the previous Celerra (NAS) product.   Celerra had SRM support for both NFS and iSCSI previously!  For Pete’s sake, how hard can it be to modify this?!?!    In a recent explanation, it was stated that the API’s were changing between SRM 4.x and 5.x.   Well, somehow every other major storage array from EMC and other manufacturers didn’t seem to have a hiccup from this in their support of SRM.   Obviously, EMC is going to focus on the high-dollar VMAX and VNX platforms first, but no excuse to let your SMB product lag this far behind.

OK, now that the rant is out of the way, what options do you have to achieve a fully replicated solution for your vSphere environment?    It really boils down to two market-proven options, though you may come across some other fringe players:

 

1)Ÿ  SRM w/ vSphere Replication

      Seamless Disaster Recovery failover and testing

      Tightly integrated into vSphere and vCenter

      Easy per-VM replication management within vCenter

      Storage agnostic – no vendor lock-in with array replication

Ÿ2) Veeam

      Leverages backup snapshot functionality to also replicate to a remote Veeam server

      Storage agnostic

      Offers ability to do a file-level restore from remote replicas

      Included as part of Veeam Backup and Replication product.

 

Here’s a table I put together showing a comparison between the two options:

  Veeam Replication SRM w/ vSphere Replication
vSphere version required 4.0 and higher 5.0 (HW Version 7 or higher required on VMs)
Replication Methodology VM Snapshots vSCSI block tracking
Realistic best-case RPO 15 min 15 min
Includes Backup Yes No
Licensing Per socket Per VM
VSS quiescing Yes (custom VSS driver) Yes (VM Tools VSS)
Replicate powered-off VMs Yes No
File Level Restore from Replica Yes No
Orchestrated Failover based on defined DR plan No Yes
Easy non-disruptive DR testing capabilities No Yes
Multiple Restore Points from Replica Yes No
Re-IP VM during failover Yes Yes

 

So, how do you choose between the two?   Well, that’s where the proverbial “it depends” answer comes in.   When I’m speaking with SMB market customers, I’ll ask questions about their backup to get a sense as to whether or not they could benefit from Veeam.   If so, then it’s certainly advantageous to try and knock-out backup and replication with one product.   However, that’s not to say that there can’t be advantages to running Veeam for backup but using SRM with vSphere Replication as well, if you truly need that extra level of automation that SRM offers.

 

UPDATE 10/2/2012

I recently got notified about an update to the original post on the EMC community forums: https://community.emc.com/thread/127434.   An EMC representative has just confirmed that the target GA date is now Q1 2013….which marks another slip.

Also, with the announcement of vSphere 5.1 came a few improvements to vSphere Replication with SRM.   Most notably, SRM now supports auto-failback with vSphere Replication, which previously was a function only supported with array-based replication.

Advertisements
Categories: EMC, Veeam, VMware

A look at Block Compression and De-duplication with Veeam and EMC VNX

March 26, 2012 4 comments

Before I proceed any further, I want to state clearly that the testing I performed was not to pit one alternative vs. another.   Rather, I was curious to do some testing to see what type of Block LUN Compression rates I could get for backup data written to a CX4/VNX, including previously de-duped data.   At the same time, I had a need to do some quick testing in the lab comparing Veeam VSS vs. VMware Tools VSS snapshot quiescing.    Since Veeam does de-duplication of data, I ended up just using the backup data that Veeam wrote to disk for my Block LUN Compression tests.

Lab Environment

My lab consists of a VNX5300, a Veeam v6 server, and vSphere 5 running on Cisco UCS.   The VM’s I backed up with Veeam included a mix of app, file, and database VMs.  App/File constituted about 50% of the data and DB was the other 50%.   By no means will I declare this to be a scientific test, but these were fairly typical VM’s that you might find in a small customer environment and I didn’t modify the data sets in any way to try and enhance results.

Veeam VSS Provider Results

For those not aware, most VADP backup products will quiesce the VM by leveraging MS VSS.  Some backup applications provide their own VSS provider (including Veeam), and others like vDR rely on the VMware VSS provider that gets installed along with VMware tools.   With Veeam, it’s possible to configure a job that quiesces the VM with or without their own provider.   My results showed the Veeam VSS provider was much faster than VMware’s native VSS.   On average Veeam created the backup snapshot in 3 seconds with their provider, and 20 seconds without it.   I also ran some continuous ping tests to the VM’s while this process was occurring, and 1/3 of the time I noticed a dropped ping or two when the snapshot was being created with VMware’s VSS provider.   A dropped ping is not necessarily a huge issue in itself, but certainly the longer the quiescing and snapshot process takes, the bigger your window for a “hiccup” to occur, which may be noticed the applications running on that server.

De-dupe and Compression Results

I ran two tests leveraging Veeam and a 200GB Thin LUN on the VNX5300.

Test 1

The settings used for this test were:

  • ·         Veeam De-dupe = ON
  • ·         Veeam In-line compression = ON
  • ·         EMC Block LUN Compression = Off
  Backup Job Size
Backup Job 1 6GB
Backup Job 2 1.2GB
Backup Job 3 12.3GB

 

The final space usage on the LUN was 42GB.   I then turned on Block LUN Compression and no additional savings were obtained, which was to be expected since the data had already been compressed.

Test 2

The settings used for this test were:

  • ·         Veeam De-dupe = ON
  • ·         Veeam In-line compression = Off
  • ·         EMC Block LUN Compression = ON
  Backup Job Size
Backup Job 1 13.6GB
Backup Job 2 3.4GB
Backup Job 3 51.3GB

 

The final space usage on the LUN was 135GB.  I then turned on VNX Block LUN Compression and the consumed space was reduced to 60GB – a 2.3:1 compression ratio or a 56% space savings.  Not too shabby for compression.   More details on how EMC’s Block LUN Compression are available at this link: http://www.emc.com/collateral/hardware/white-papers/h8045-data-compression-wp.pdf

In short, it looks at 64KB segments of data and tries to compress data within each segment. 

Again, this post isn’t about comparing de-dupe or compression rates between Veeam’s software approach within the backup job, or letting the storage hardware do the work.   There are going to be pros and cons to both methods.   For longer retentions (30 days and beyond), I tend to recommend a Purpose-built Backup Appliance (PBBA) that does variable-length block de-duplication.  Rather, for these tests I was out to confirm:

a)      Does Block LUN Compression work well for backup data (whether it has been de-duped or not)?  The conclusion here was Block LUN Compression worked quite well.  I really didn’t know what to expect, so the results were a pleasant surprise.   In hindsight, it does make sense that the data could still compress fairly well.   Although de-dupe has eliminated redundant patterns of blocks, if the remaining post-dedupe blocks still contain data that is compressable, you should be able to squeeze more out of it. This could come in handy for situations where B2D is leveraged and your backup software doesn’t offer compression, or shorter retentions that don’t warrant a PBBA that does variable-length block de-duplication.   

 

b)      The latest version of Veeam is quite impressive, they’ve done some nice things to enhance the architecture so it can scale out as larger enterprise backup software does.   The level of de-dupe and compression achieved within the software was impressive as well.   I can certainly understand why a large number of mid-market customers I speak with have little interest in using vDR for VM image backups as Veeam is still light-years ahead.    If you’re looking at these two products and you have highly-transactional systems in your environment such as busy SQL or Exchange boxes, you’ll be better off with Veeam and its enhanced VSS capabilities. 

Categories: Backup, De-dupe, EMC, Veeam, VMware

Is the end of the File Server finally in sight?

December 28, 2011 Leave a comment

A year ago I wrote an article detailing my thoughts on how greatly exaggerated predictions of the imminent death of the file server truly were. A few years back many thought the file server would be gone by now, replaced by SharePoint or other similar content portals. Today, file servers (herein referenced as NAS) are alive and well, storing more unstructured content than ever before. You can read the original article here: http://bit.ly/t573Ry

In summary, the main reasons why NAS has not disappeared are:

  • Much of the content stored on NAS is simply not suitable for being stored in a database, and middleware technologies that allow the data to stay on NAS but be presented as if it were in the database adds complexity.
  • Legacy environments are often too big to accommodate a migration of all user and department shared files into a new repository in a cost effective manner.
  • Legacy environments often have legacy apps that were hard-coded to use UNC paths or mapped drive letters.
  • Many businesses in various industries have instruments or machinery that write data to a network share to store data using commonly accepted CIFS and NFS protocols.
  • The bulk of file growth today is in larger rich media formats, which are not well-suited for SharePoint.
  • NAS is a great option for VMware using NFS

The other day I found myself in a presentation where the file server is dead claim was made once again, and the very thought crossed my mind as well after seeing some examples of impressive technology hitting the street. What’s driving the new claims? Not just cloud storage (internal or external), but more specifically Cloud storage with CIFS/NFS gateways and sync and share capabilities with mobile devices.

EMC’s Atmos is certainly one technology playing in this space, another other is Nirvanix. I’ve also had some exposure to Oxygen Cloud and am really impressed with their corporate IT friendly DropBox-like offering. So how do these solutions replace NAS? Most would agree that the consumerization of corporate IT is a trend going on in the workplace right now. Many companies are considering “Bring your own device” deployments instead of supplying desktops and laptops to everyone. Many users (such as doctors) are adopting tablet technology on their own to make themselves more productive at work. Additionally, many users are using consumer-oriented websites like DropBox to collaborate at work. The cloud storage solutions augment or replace the file server by providing functionality similar to these public cloud services, but the data resides inside the corporate firewall. Instead of a home drive or department share, a user gets a “space” with a private folder and shared folders. New technologies allow that shared space to be accessed by traditional NFS or CIFS protocols, as a local drive letter, via mobile devices, or via a web-based interface. Users can also generate links that expire within X number of hours or days that allow an external user to access one of their files, without the needing to email a copy of the document or put it out on DropBox, FTP, etc.

The one challenge I see is that no single solution does everything yet, meaning CIFS/NFS, web-based, and mobile sync and share. Atmos can do CIFS/NFS, but mobile device access requires something like Oxygen. Nirvanix also does just CIFS/NFS. Oxygen by itself isn’t really setup to be an internal CIFS/NFS access gateway, it’s primarily intended for web/mobile sync and share use cases. Panzura, Nasuni, etc offer CIFS/NFS or iSCSI gateway access to the cloud, but they don’t offer sync and share to mobile devices. You could certainly cobble together something that does everything by putting appliances in front of gateways that sit in front of a storage platform, but then it starts to become difficult to justify the effort. You’d also have to consider the fact you’ll need to re-architect within 12-18 months when more streamlined solutions are available. Either way, file sharing is still an exciting place to be with lots of change occurring in the industry. I can definitely see the possibility of home drives and department/workgroup shares going away into a private cloud offering, but the concept of file sharing is certainly still alive and well and CIFS/NFS isn’t going anywhere anytime soon. I don’t like to make predictions, but at this point my best guess is the technology that can do the best job of integrating legacy NFS/CIFS not just with “cloud storage”, but with web-friendly access and mobile device access that accelerate the consumerization trends will be the winner in this race.

Categories: Cloud, EMC, NAS, SAN Tags:

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 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

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 (http://bit.ly/knqCqT). 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: http://bit.ly/msr7Hs):

  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

Does Archiving to Centera or CAS Still Matter?

May 4, 2011 3 comments

Over the past 2 years, I’ve noticed a rather drastic reduction in the number of archiving conversations I have with customers. Email archiving still pops up, but most of the folks who need to do it are already doing it. File system archiving seems to be even less common these days, though it still pops up occasionally. There is certainly still a market in healthcare and financials, but even that seems less prevalent than it was at one time. Archiving did come up in a recent conversation, which got me thinking about this topic again and I thought it’d make a good blog post.

Without a doubt, the archive market seems to have shrunk. I’m reminded of my time at EMC a year and a half ago when I had to go thru some training about “recapturing the archive market”. From the early-mid 2000’s until the late 2000’s, the “archive first” story was the hottest thing going. EMC built an entire business on the Backup, Recovery, and Archive story (BURA), which encompassed the idea of archiving your static and stale data first, to save money by shrinking the amount of data you need to back up and store on more expensive Tier 1 storage. As a result, they made the term Content Addressable Storage (CAS) go mainstream and be copied by others.  The Centera platform was a product EMC purchased rather than developed in-house, but they created a successful business out of it nonetheless. The predecessor of the Centera was a product called FilePool. The founders of FilePool are actively involved in another CAS startup now called Caringo.

How CAS Works

The Content Address is a digital fingerprint of the content. Created mathematically from the content itself, the Content Address represents the object—change the binary representation of the object, (e.g. edit the file in any way) and the Content Address changes. This feature guarantees authenticity—either the original document remains unchanged or the content has been modified and a new Content Address is created.

Step 1 An object (file, BLOB) is created by a user or application.
Step 2 The application sends the object to CAS system for storing.
Step 3 CAS system calculates the object’s Content Address or “fingerprint,” a globally unique identifier.
Step 4 CAS system then sends the Content Address back to the application.
Step 5 The applications store the Content Address—not the object—for future reference. When an application wants to recall the object, it sends the Content Address to the CAS system, and it retrieves the object. There is no filesystem or logical unit for the application to manage.

CAS systems also had another compelling advantage back in the day, that being there was very little storage management involved. No RAID groups, LUNs, or Storage Groups to ever build or allocate. No traditional file system to ever manage. Per IDC, a full time employee could effectively manage considerably more CAS storage than any other type (320TB vs. 25TB for NAS/SAN).

I have to admit, the CAS story was compelling. Thousands of customers signed up and bought hundreds of PB’s of CAS from multiple vendors. The Fortune 150 company I worked for in the past implemented hundreds of TB’s of Centera CAS as part of an archiving strategy. We archived file system, database, and email data to the system using a variety of ISV packages. Given that this market used to be so hot, I’ve often thought about the possible scenarios for it cooling off, and why many people now choose to use a Unified storage platform for archiving rather than a purpose-built CAS system. Here are a few of the thoughts I’ve had so far (comments welcome and appreciated):

  1. CAS wasn’t as simple as claimed. Despite the claims of zero storage management, in reality I think several of the admin tasks that were eliminated by CAS were replaced by new management activities that were required for CAS. Designing archive processes with your internal business customers, evaluating various archiving software packages, configuring those software packages to work with your CAS system, and troubleshooting those software packages can be cumbersome and time-consuming.
  2. Storage management has gotten considerably easier in the last 5 years.   Most vendors have moved from RAID groups to pool’s, LUN/Volume creation is handled via GUI instead of CLI, and the GUI’s have been streamlined and made easy for the IT generalist to use.   Although I would say a CAS appliance can still be easier to manage at scale, the difference is not near as great as it was in 2005.
  3. NetApp created a great story with their one size fits all approach when they built in WORM functionality to their Unified storage platform, which was soon copied by EMC in the Celerra product and enhanced to include compliance.
  4. Many customers didn’t need guaranteed content authenticity that CAS offers, they simply needed basic archiving. Before NetApp and EMC Unified platforms offered this capability, Centera and other CAS platforms were the only choice for a dedicated archive storage box. Once NetApp and then EMC built in archiving into the cost-effective mid-range Unified platform, my opinion is it cut Centera and other CAS systems off at the knees.
  5. CAS systems were not cheap, even if they could have a better TCO than Tier 1 SAN storage. It was primarily larger enterprises that were typically able to afford CAS, while the lower-end of the market quickly gravitated to a Unified box that had archive functionality built in.
  6. Backup windows were not always reduced by archiving. Certainly there were some cases where it could help, but also areas where it did not. As an example, many customers wanted to do file system archiving on file systems with millions and millions of files. When you archive, the data is copied to the archive and a stub is left in the original file system. Using traditional backup, these stubs still need to be backed up, and the backup application sees them as a file. This means even if the stub is only 1KB, it still causes the backup application to slow way down as part of the catalog indexing process. There are some workarounds like doing a volume-based backup, which backs up the file system as an image. However, there are caveats here as well. As an example, if you do file-system de-dupe on an EMC platform in conjunction with archiving, you can no longer do granular file-level recoveries from a volume-based backup. Only a full-destructive restore is allowed.
  7. Many customers didn’t really need to archive for compliance purposes, rather they simply wanted to save money by moving stale data from Tier 1 storage to Tier2/3 storage. This required adding in cost and complexity for a file migration appliance or ISV software package to perform the file movement between tiers, which ate away at the cost savings. Now that many storage arrays have auto-tiering functionality built-in, the system will automatically send less frequently accessed blocks of data to a lower tier of storage, completely transparent to the admin and end-user, with no file stubbing required.

To sum it up, what would I recommend to a customer today? CAS is still a very important storage product and although it’s not a rapidly growing area, it still has a significant install base that will remain for some time. There still are some things that a CAS system can do that the Unified boxes cannot. Guaranteed content authenticity with an object-based storage model is certainly one of those, and probably the most important. If you require as good of a guarantee as you can possibly get that your archive data is safe, CAS is the way to go. As I alluded to before, this still has importance in the healthcare and financial verticals, though I see smaller institutions in those verticals often choose a Unified platform for cost-effectiveness. Outside of those verticals, if your archive storage needs are <100TB, I’m of the opinion that a Unified platform is most likely the way to go, keeping in mind every environment can be unique. There may also be exceptions for applications that offer CAS API integration thru the XAM protocol. If you’re using one of those applications, then it may also make sense to investigate a true CAS platform.

Further reading on CAS:

http://en.wikipedia.org/wiki/Content-addressable_storage

Categories: Archive, Backup, EMC, NAS, NetApp