Cohesity Basics – Configuring An External Target For Cloud Archive

I’ve been working in the lab with Pure Storage’s ObjectEngine and thought it might be nice to document the process to set it up as an external target for use with Cohesity’s Cloud Archive capability. I’ve written in the past about Cloud Tier and Cloud Archive, but in that article I focused more on the Cloud Tier capability. I don’t want to sound too pretentious, but I’ll quote myself from the other article: “With Cloud Archive you can send copies of snapshots up to the cloud to keep as a copy separate to the backup data you might have replicated to a secondary appliance. This is useful if you have some requirement to keep a monthly or six-monthly copy somewhere for compliance reasons.”

I would like to be clear that this process hasn’t been blessed or vetted by Pure Storage or Cohesity. I imagine they are working on delivering a validated solution at some stage, as they have with Veeam and Commvault. So don’t go out and jam this in production and complain to me when Pure or Cohesity tell you it’s wrong.

There are a couple of ways you can configure an external target via the Cohesity UI. In this example, I’ll do it from the dashboard, rather than during the protection job configuration. Click on Protection and select External Target.

You’ll then be presented with the New Target configuration dialogue.

In this example, I’m calling my external target PureOE, and setting its purpose as Archival (as opposed to Tiering).

The Type of target is “S3 Compatible”.

Once you select that, you’ll be asked for a bunch of S3-type information, including Bucket Name and Access Key ID. This assumes you’ve already created the bucket and configured appropriate security on the ObjectEngine side of things.

Enter the required information. I’ve de-selected compression and source side deduplication, as I’m wanting that the data reduction to be done by the ObjectEngine. I’ve also disabled encryption, as I’m guessing this will have an impact on the ObjectEngine as well. I need to confirm that with my friends at Pure. I’m using the fully qualified domain name of the ObjectEngine as the endpoint here as well.

Once you click on Register, you’ll be presented with a summary of the configuration.

You’re then right to use this as an external target for Archival parts of protection jobs within your Cohesity environment. Once you’ve run a few protection jobs, you should start to see files within the test bucket on the ObjectEngine. Don’t forget that, as fas as I’m aware, it’s still very difficult (impossible?) to remove external targets from the the Cohesity Data Platform, so don’t get too carried away with configuring a bunch of different test targets thinking that you can remove them later.

Cloudian Announces HyperStore 4000 – Gets Super Dense

I’ve written about Cloudian before, having had the good fortune of seeing them present at Storage Field Day 7 and Storage Field Day 10. I recently had the opportunity to be briefed by Jon Toor, Cloudian’s CMO, on the HyperStore 4000 (the datasheet can be found here and Cloudian’s press release can be found here).

 

Super Dense Spec

[image via Cloudian]

The HyperStore 4000 comes with two nodes per chassis, each with 2 Intel E5-2620 v4, 8 core CPUs and 128GB RAM. There are 35 hot-swap 3.5″ drives per node, with 2 800GB hot-swap SSDs per node and 10GbE networking (same as the HyperStore 1500).

With raw capacity of 700TB in a 4RU enclosure, Cloudian tell me the HyperStore 4000 reduces storage costs by 40 percent versus their previous solutions.

It also offers:

  • Data availability is enhanced by the resilient hardware architecture (two compute nodes per chassis), delivering 99.999999 percent data durability from a three-appliance cluster; and
  • Built-in hybrid cloud tiering (to Amazon S3 or Google Cloud) enables customers to optimize their storage model with a combination of on-premises Cloudian storage and public cloud storage.

 

Thoughts

I’ve written about Cloudian’s S3 guarantee before – and this is still a big part of the value proposition. I spoke to Jon about where he saw uptake in Cloudian (and object storage in general) in the enterprise. He talked about data protection on-premises being the obvious problem being solved with object and spoke of object storage cost approaching the same economics as tape. But there’s other stuff you can use object storage for too, including media asset managers (using S3 compliance) and video surveillance. Most of the software on the market has some kind of hook into S3, and this is heavily leveraged by Cloudian to provide the same services on-premises.

But object storage (and Cloudian in particular) is not just about cheap and deep. Object does distributed storage really well too. Jon spoke about Cloudian providing good, verifiable visibility into data locality. This can be extremely important for government authorities and businesses with a requirement to focus not just on how their data is stored, but also where.

If you’re in the market for some nice, dense, smart object storage, I’d encourage you to look further into the Cloudian offering. For another perspective on the HyperStore 4000 announcement, El Reg has a good summary here.

SwiftStack Announces Object Storage Version 4.0

If you’ve not heard of SwiftStack before, they do “object storage for the enterprise”, with the core product built on OpenStack Swift. I recently had the opportunity to be briefed by Mario Blandini on their 4.0 announcement. Mario describes them as “Like Amazon cloud but inside your DC and behind your firewall”.

New SwiftStack 4.0 innovations introduced today (and available now or in the next 90 days) include:

  • Integrated load balancing reducing the need for expensive dedicated network hardware and minimizing latency and bandwidth costs while scaling to larger numbers of storage nodes
  • Metadata search increases business value with integrated third-party indexing and search services to make stored object data analytics-ready
  • SwiftStack Drive is an optional desktop client that enables access to objects directly from desktops or laptops
  • Enhanced management with new IPv6 support, capacity planning and advanced data migration tools

Swift00

One of the key points in this announcement is the metadata search capability. Object storage is not just about “cheap and deep”, and the way we use metadata can have a big impact on the value of the data, often to applications that didn’t necessarily generate the data in the first place.

Like all good scale out solutions, you don’t need to buy everything up front, just what you need to get started. SwiftStack aren’t in the hardware business though, so you’ll be rolling your own. The hardware requirements for SwiftStack are here, and there’s also a reference architecture for Cisco.

 

Futures

SwiftStack have plans to introduce “Swift File Access” in 2016

Swift00_File

Some of the benefits of this include:

  • Scale-out file services; SMB and NFS – minimizes the need for gateways
  • Fully bimodal > files can come in over SMB and accessed through object APIs and visa versa
  • Integrated into the proxy role > performance scales independently of capacity

SwiftStack also have plans to introduce “Object Synchronization” in 2016

Swift00_ObjectSync

This will provide S3 Synchronization capability, including

  • Replication of objects to S3 buckets
  • Policy-driven > protecting and accessing files using centralized policies
  • Supporting any cloud compatible with the S3 API

This is pretty cool as there’s a lot of momentum within enterprises to consume data in places where it’s needed, not necessarily where it’s created.

 

Final Thoughts

Object storage is hot, because folks love cloud, and object is a big part of that. I like what object can do for storage, particularly as it relates to metadata and scale out performance. I’m happy to see SwiftStack making a decent play inside the enterprise, rather than aiming to be just another public cloud storage provider. I think they’re worth checking out, particularly if you have data that could benefit from object storage without necessarily having live in the public cloud.