Hey there! This week we announced the upcoming release of our latest operating environment for the FlashArray: Purity 6.0. There are quite a few new features, details of which I will get into in subsequent posts, but I wanted to focus on one related topic for now. Replication. We have had array based replication (in many forms) for years now, in Purity 6 we introduced a new offering called ActiveDR.
ActiveDR at a high level is a near-zero RPO replication solution. When the data gets written, we send it to the second array as fast as we can–there is no waiting for some set interval. This is not a fundamentally new concept. Asynchronous replication has been around for a long time and in fact we already support a version of asynchronous. What is DIFFERENT about ActiveDR, is how much thought has gone into the design to ensure simplicity while taking advantage of how the FlashArray is built. A LOT of thought went into the design–lessons learned from our own replication solutions and features and of course lessons from history around what people have found traditionally painful with asynchronous replication. But importantly–ActiveDR isn’t just about replicating your new writes–but also snapshots, protection schedules, volume configurations, and more. It protects your protection! More on that in the 2nd part.
Hey there! This week we announced the upcoming release of our latest operating environment for the FlashArray: Purity 6.0. There are quite a few new features, details of which I will get into in subsequent posts, but I wanted to focus on one related topic for now. Replication. We have had array based replication (in many forms) for years now, in Purity 6 we introduced a new offering called ActiveDR.
ActiveDR at a high level is a near-zero RPO replication solution. When the data gets written, we send it to the second array as fast as we can–there is no waiting for some set interval. This is not a fundamentally new concept. Asynchronous replication has been around for a long time and in fact we already support a version of asynchronous. What is DIFFERENT about ActiveDR, is how much thought has gone into the design to ensure simplicity while taking advantage of how the FlashArray is built. A LOT of thought went into the design–lessons learned from our own replication solutions and features and of course lessons from history around what people have found traditionally painful with asynchronous replication. But importantly–ActiveDR isn’t just about replicating your new writes–but also snapshots, protection schedules, volume configurations, and more. It protects your protection! More on that in the 2nd part.
One of the new features in vSphere 7 is support for NVMe-oF (Non-Volatile Memory Express over Fabric)–this replaces SCSI as a protocol and extends the NVMe command set over an external (to the host) fabric.
So what is it and why? I think this is worth a quick walk down memory lane to really answer both of these questions.
Before I get into it, below is a recent video/podcast/roundtable I did with the Gestalt IT with a few wonderful people:
Christopher Kusek
Greg Stuart
Jason Massae
Stephen Foskett
The premise is “Is NVMe-oF ready for the primetime?” Check it out and find out where we all land! For more on my thoughts, read on.
Quick post, I did a quick google and found nothing immediately on this, so figured a quick post might be helpful for folks. My new install of Windows Terminal was defaulting to PowerShell 5:
And to switch to 7.0.1 (core) I had to go to the dropdown and open it each time. Such drudgery!
Of course this is probably gets an old “big deal, I’ve had that on Linux or Mac since the stone age” from those users. And fair enough.
Anyways, regardless to your platform, you might be a PowerShell user–since PowerShell Core is supported on multiple platforms. If you are a PowerCLI user, VMware added support a few years ago. Our base PowerShell modules (for direct management of the FA) does not yet support Core, though it is in plan. We also offer a VMware-focused Pure Storage PowerShell Module which connects PowerCLI commands with FlashArray operations (when needed) to managing a VMware and Pure environment a streamlined experience in PowerShell. This module has some cmdlets that have dependencies on both, and some have dependencies on just one of the two. The latter situation is what I am working on.
At long last! vSphere 7 is available for download.
An overview podcast on whats up:
As time progresses we will have a lot more content out–especially new integrations around the VMware ecosystem. So certainly stay tuned, this is just the start!
It’s a good listen–and it did get me thinking about vVols (like most things do these days). Before I get into that though… We (Pure) are doing a fair amount around helping customers protect against, or at least easily recover from ransomware attacks. My personal thinking around this is certainly still evolving, and I have a fair amount to learn, but here are a few things I think are important points.
Ransomware attacks do not begin and end with encryption of your data. Generally, once an attacker gets in they find out what they can do. What can they access? What can they disable? Can they disable your protection? It is worth their time to figure the answers to these questions out. The more damage they do to your protection, the more likely they will get paid.
You need to ASSUME that the attacker has gained administrative credentials. In building your protection, good RBAC is a part of but not the end all, be all. A disgruntled sys admin even–doesn’t have to be a shadowy figure in a cave.
Look at the forest and the trees. Protection requires consideration of each component (as an admin of this piece of the infrastructure how can I protect what I am in charge of?) and consideration of the entire infrastructure (how do I protect my business if an entire part of my stack gets compromised?).
Prevention, insulation, detection, mitigation, and restore. My five phases of ransomware.
How can I prevent it?
How can I reduce the blast radius if one part or many get successfully attacked?
Can I detect it?
How can I stop it?
How would I restore and how quickly?
When did the attack actually start? Restoring to a non-encrypted version doesn’t mean it isn’t infected. Having access to longer-term point-in-time, while still having fast restore is important.
This is a new kind of “what’s new” than what I usually talk about–it is not really a “storage” feature in the specific sense. But it is a really useful one that I intend to use a lot.
A common traditional problem was knowing what was going on in the guest from a storage perspective. If you want to script something against the vSphere API (unmount this file system) then do something with the virtual disk, then do something on the storage. Now it was possible to use the in-guest API, but because it required additional credentials to get into the VM and was a multiple step operation, it didn’t scale very well if you need to query information from a bunch of VMs.
The ideal scenario would be for VMware tools to report this vCenter so it can easily be pulled from the API, right?
Ah it’s time for another round of “what’s new” with vSphere external storage. Before I get into the more traditional feature version of this series, I wanted to first note some important announcements around vVols.
So the first thing that’s “new” in storage with vSphere 7.0 is that VMware is taking vVols extremely seriously now. 2018 and vVols was about spreading the value of vVols, 2019 was about getting vendors to dig in, and 2020 is about VMware and storage partners delivering on it. This is just the start.
Site Recovery Manager
This is, of course, the big one. You can check out the announcement here:
Since day 1 of SRM, array-based replication was of primary importance. SRM was essentially built to provide a common orchestration tool for disaster recovery. It automated the VMware steps of recovering virtual machines while coordinating with the underlying replication on the array to make sure the data was on site B and was ready to be used when needed. This coordination was through something called a Storage Replication Adapter (an SRA).
The fundamental problem around SRAs were the fact that it was entirely a SRM “thing”. Replication configuration and management had to be done elsewhere. It couldn’t be done natively in vSphere–best case there was a vSphere Plugin that could help, but once again that only integrated the configuration of replication into the UI, not into vSphere itself, so managing changes wasn’t scalable. Furthermore, every vendor did it differently (if they even had a plugin that could do it).
There was ZERO consistency beyond how SRM ran recovery plans. This is what vVol replication integration was designed to fix.
First off, it integrates directly with VM provisioning and policy-based management. So there is no need to install or use a plugin to manage replication protection for VMs. It is also built into vSphere itself, not just the UI. This allows it to be managed and configured however you manage vSphere (PowerCLI, vRO, vRA, Python, etc) without additional plugins.
As vVols have REALLY picked up steam in the last year. VMware has re-focused its efforts on making sure lingering issues/gaps were fixed that were preventing further vVol adoption. This is/was a common sentiment from customers:
Let’s be clear here: the stated path for VMware storage of the future is vVols and vSAN. VMware is obviously finally committing to this ideal.
So now in SRM, you can create a protection group that discovers replicated VMs not via the SRA, but by querying the vSphere API directly for vVol replication groups.
So you add vVol replication groups directly to SRM protection group–very similar in concept via datastore groups via SRA-based policies.
When you choose a SPBM policy for a given VM–you then choose a replication group (if it is a replication type policy). As you add (or remove) VMs to the replication group, they will be automatically protected by SRM (or unprotected). Further integrating the process into SPBM.
Stay tuned for a lot more on this!
vRealize Operations Manager
vRealize Operations Manager (vROps) is a fantastic tool for datacenter trending, analysis, balancing, monitoring, etc. Many vendors have what is called a management pack which integrates their specific objects,metrics, and alerts into vROps so it can be associated with their various related VMware objects (and their metrics, alerts, and their own related objects).
When it came to vVols, there was a gap–vROps didnt quite know how to understand a vVol datastore. Therefore it didn’t know how to relate VMs and their disks. Therefore the vendor couldnt really relate them to their storage objects. So any vVol integration by vendors there was at best half done.
So in vROps 8.1 the vVol datastore exists:
This opens up a whole new world of storage management packs! I’m very excited to build more onto our management pack to take advantage of this final connector we needed!
vSphere with Kubernetes
Project Pacific no more! There are a lot of places to get more information on this, though a great place to get a start is here:
In short, tightly integrating K8s into vSphere. Manage and control your containers/K8s pods as a 1st class citizen, just like your VMs of yore.
Persistent storage is presented through the VMware CSI driver, called CNS (Cloud Native Storage). CNS uses existing storage options for storage provisioning, but in a new way. First it is based of of Storage Policy Based Manager (your storage classes for CSI provisioning are based on policies) furthermore, it uses first class disks instead of standard disks which I talk about here:
They are just virtual disks, but in the API they are 1st class objects–they can be created and exist independently of a VM. Which makes sense for something that is not a VM (or more to the point something that might not be as persistent as a VM) like a container.
FCDs can be created, snapshotted, resized, etc just like a virtual disk but without a VM to own it. Sounds a lot like a persistent volume claim!
vVols + FCDs make this story even better, because configuration is controlled in policies (get, set, check) and the volume is a 1st class object on the array too. On the FlashArray, since vVols are just volumes if that persistent volume claim (that volume) is in use in a non-VMware K8s environment it should be easily imported into vSphere with Kubernetes through a vVol FCD. Look for more information as we build out documentation and tools around this.
Very excited about the future of this!
VMware Cloud Foundations
The mother of all VMware automation. I blogged about it while ago here:
This is becoming more and more important and VMware is improving it to have better storage integration into SDDC manager as shown above. VMware has announced partner support of vVols as supplementary storage (we will have documentation on that very soon) which is just the start.
This is just the start to vVols in 2020! Stay tuned!
