Cohesity is changing the definition of secondary storage

Cohesity LogoBack at Storage Field Day 8, Cohesity presented their newly announced solution to optimize secondary storage usage and how to get more bang for your buck on secondary storage. One critical thing to note here is that Cohesity changes the definition of secondary storage! In their view, secondary storage is everything that’s not Tier 1, high performance, mission critical stuff. So yes, that’s backups.. but it’s also test and development, file shares, archives, etc.

The Cohesity Platform

Cohesity wants to consolidate all your secondary storage on one system in a web-scale manner:

  • Infinitely/incrementally scalable
  • With no single point of bottleneck
  • Components may be down indefinitely – there’s no need for a sysadmin to replace a broken part within 15 minutes, it can wait till the next scheduled data center visit
  • Always available, during normal operations and during upgrades
  • With heterogeneous hardware

Their hardware platform currently comes in two flavors, with the biggest difference being hardware.

Cohesity hardware

The C2500 blocks are 96TB each, with the smaller C2300 at 48TB per 2U block. Cohesity has tested a 32-node system that maxed out at 3PB; their biggest customer install in the field is currently 12 nodes.

Each node contains some PCI-e based Flash. The Cohesity distributed architecture called OASIS (Open Architecture for Scalable Intelligent Storage) writes data to the two tiers in a manner that depends on the underlying storage technology: Cohesity calls it TOWS or Tier-Optimized Write Scheme. Spinning disks prefer sequential I/O and thus writes data out-of-place; an SSD doesn’t mind random I/O so incoming writes are placed in the “correct” location straight away.

The Cohesity system integrates into VMware environments using VADP. In case an incremental backup is sent to the C2000 systems, this data is combined with the original full backup. The backups are also file aware, i.e. you can browse the VMDKs and restore individual files from within the VMDK. If you want to restore a virtual machine you can either restore it to primary storage, or power it on the Cohesity appliance and then storage VMotion it back to the production system.

OASIS in its foundation supports a pretty impressive analytics workbench, that can for example be used for PII compliance checks. If one of the standard Analytics workloads don’t suit you, you can inject your own custom code via a Java interface and run for example a customized search for SSNs. Check out the demo of this in the second-to-last video located over here.

My thoughts on Cohesity

Cohesity redefines the concept and definition of secondary storage. For them, primary storage is mission critical apps and secondary storage is basically everything else. There’s a lot to be gained by consolidating all these different copies of data in one system, which is why they focus on this part of the data infrastructure.

In principle I completely agree. Each copy of data costs money. If you can consolidate those copies and put them to use with something that actually raises company income, go for it. It’s the profitable thing to do.

I start to look a bit more worried when you are consolidating live data and backups on one system. You’re now putting all your eggs in one basket. The only reason we make backups of data is that we want to be able to restore data in case we need to. Backing up your Tier 1 applications to the Cohesity systems: no problem. Running some analytics on this data: sure! Store some files shares on the Cohesity systems to use left-over capacity: why not. Back up those file shares to the same Cohesity cluster: in my opinion, hell no.

If you want to play it safe, backup data should be in a different system than your production copy. Preferably in a completely different type of system. You want to defend against data corruption and accidental deletion, but also against faulty software releases, hackers and what-not. Which is where the definition of primary and secondary storage comes in: secondary storage is a copy of primary storage. Thankfully, the Cohesity systems support replication, both inside the Cohesity cluster, to a second cluster or to the cloud, so this shouldn’t be a limitation in those use cases. See the comment section below for more info.

Terminology wise I think the Cohesity approach in deviating from infrastructure-wide definitions like primary and secondary storage is risky. In my experience IT projects fail primarily on communication problems. If I’d have to pick a ratio, its 80% communication and only 20% technology. If you change definitions that everyone in the room considers a given, there’s bound to be problems later on. Expectations shift, someone assumes something and before you know it there’s trouble.

The Cohesity products went GA a couple of days before the Storage Field Day 8 presentation took place. It’s still a 1.0 product and it will take some time to find its place and grow into it. Cohesity is trying to cover a whole lot of use cases and if they get their marketing message exactly right, they will definitely succeed in a number of those areas. I’m curious to see how they will do in 2016: their foundation looks solid, now it’s a matter of applying it to the right use cases.

If you want to read the comments by other delegates, check out Scott’s postDan’s post or this post by Mark.

Disclaimer: GestaltIT paid for the flight, hotel and various other expenses to make it possible for me to attend SFD8. I was however not compensated for my time and there is no requirement to blog or tweet about any of the presentations. Everything I post is of my own accord.

  • Disclosure: Nick Howell, Tech Evangelist for Cohesity


    Thanks for the great piece! I wanted to clear up one thing where you showed concern with regards to backing up unstructured data (i.e. file shares).

    I think it’s fair to say that most enterprises consider a user’s home directory as “less critical” than the databases and applications that run a business. This explains why you see them hosted on a lower tier of storage, say on a NetApp or Windows file server and not on that million dollar VMAX, for example. This creates the need to have replica’s off-box in another place, be that to another system, to tape, or even to the cloud. This was the problem we initially set out to solve: having an additional island of storage just to host file shares.

    When storing/hosting file shares on the Cohesity platform, you’re natively fault tolerant due to the way we handle fanning writes across all nodes in the cluster (minimum two writes of the data itself, strictly consistent, and three writes of the metadata, with built-in chassis and rack-awareness). The difference here between this and other forms of backup is that the source is usually off-box (i.e. VMware, App servers, etc). We fully expect customers to take advantage of replication and for this to be the solution for more generic data that we’re hosting.

    That replication can happen in a number of ways: Intracluster (think volume –> volume), Intercluster (on-prem or off-site), and to the cloud via our built-in integrations with Nearline and Amazon.

    Replication is just one of the policy attributes that can be applied to a Data Protection Profile, and we’ll be introducing this UI element in an upcoming version.

    Hope this helps clear that up, and thanks again for your feedback!

    • Jon Klaus

      Hi Nick,

      Thanks for your comment! I agree that companies will have some “less critical” data that doesn’t need a second copy and maybe doesn’t even need a backup. For the companies that do want a second physical copy in a different system, the replication attribute to a second Cohesity system or the cloud should do the trick. I have seen a couple of customers that want a copy in a completely different platform (vendor and/or system) for security reasons, but those are the exception.
      I’ll update the original post and add a quick pointer regarding the replication.