It’s hard to believe that just three short months ago I was writing about Rubrik’s Cloud Data Management 3.1 announcement. Following our regular release cadence, the 3.1 release included such goodies as bare-metal Windows Server protection, Windows Server Failover Cluster (WSFC) support, reporting with Rubrik Envision, software encryption options, and a ton more. Now that 3.1 has been GA for a while, it’s time to cover some of the highlights from the recently published Cloud Data Management 3.2 announcement.
Before I get nerdy, though, let me take a moment to find a rickety soapbox. Cloud is a interesting and somewhat intangible concept. You can run workloads in the cloud, store things in the cloud, or even just leverage bits of code using Functions as a Service (FaaS – also known as Serverless). With so many available use cases out there, it’s no wonder that many folks are dipping a toe into the cloud at different starting points.
As referenced in the Phase 1 portion of the graphic below, consuming cloud storage is a simple and safe way to begin using cloud resources for many enterprises – send over deduplicated, compressed, and encrypted data (using your keys) onto blob / object storage while sweeping the floor of any legacy technologies that are holding back data visibility or consumption.
Both public and private clouds can offer so much more – I won’t go too far into the weeds, but Phase 2 and 3 point out cloud native applications, disaster recovery scenarios, consuming SaaS (Software as a Service) applications / services, and even becoming mobile across clouds. These use cases are interesting to tease apart while also requiring a new perspective on how to handle data at scale.
Alright, I’ll jump down off my pondering soap box for a moment and get to the techy bits. 🙂
The New 3.2 Features
As prefaced in the previous section, the first major innovation is the ability to run a Rubrik Cloud Cluster. This results in having a multi-node Rubrik environment running in your choice of Amazon or Azure with a starting point of 4 nodes. Because Cloud Data Management (CDM) is all about the software, there is nothing special to do beyond instantiating the Rubrik cluster. All of the benefits received from a physical cluster – always-on erasure coding, protection of virtualized and OS native workloads, replication, archival, and so forth – are included.
This allows folks to begin the journey of protecting their cloud native applications directly to Rubrik CDM within the same cloud where the applications are running. And because the system is designed to be topology agnostic, data can be replicated to any other Rubrik instance such as to another Rubrik Cloud Cluster running in a different public cloud or perhaps to an on-premises data center. Archive is supported in the same fashion; archive locally to an object or blob storage or send the data to some other supported archive target. There’s lots of options here to meet the functional requirements set forth by the business needs.
On top of this, Rubrik 3.2 has native support for protecting NAS shares. While one could do this prior to the 3.2 release by talking to a Windows or Linux host, the new native NAS support makes it simpler. Just input the NFS or SMB path, provide credentials (if required), and assign an SLA policy. That’s it; you’re done. Fairly snazzy, simple, and elegant. Plus, all of the files will remain globally searchable and available for restoration or download even after being replicated or archived to a remote location.
Speaking of replication, the new release allows for per-SLA policy replication streams. Previously, an entire Rubrik cluster would replicate to only one other Rubrik cluster, and each SLA policy could optionally participate in replication. With 3.2, you can configure as many replication targets as desired and select the desired target within an SLA policy. For example: configure the Gold SLA policy to replicate 14 days worth of data to your DR site, while also configuring your Silver SLA policy to replicate 3 days worth of data to a Cloud Cluster for test and development workloads.
And finally, enhancements were to allow unique SLA assignments to on-demand snapshots. Primarily, the use case of on-demand snapshots are for ad-hoc backups prior to testing an application patch, upgrade, or some sort of “roll back” plan to put a workload, server, database, virtual machine, or fileset back to its original state. I see two major use cases for this:
- Quick Tests: you want to retain an on-demand snapshot for a very short time and have it thrown away automatically and ensure it doesn’t get replicated across the WAN. Choose an SLA policy with a short lifespan and no replication or archive.
- Longer / Regression Tests: you want to hang onto an on-demand snapshot but don’t want to pay the performance penalty tax of a virtual machine snapshot. Use a more standard policy with a longer lifespan that also offers replication or archive features.
While I’m just scratching the surface to the 3.2 announcement, I’ll fade out at this point and state that I’m quite excited about all of the groovy goodies baked into these latest bits of code. If you’d like to learn more, check out Andrew Miller’s webinar entitled Cloud Capabilities – Less Talk, More Action with Rubrik 3.2 on Thursday, May 11 at 8AM PT / 11AM ET. Enjoy!