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.
Note: This is another guest blog by Kyle Grossmiller. Kyle is a Sr. Solutions Architect at Pure and works with Cody on all things VMware.
One of the (many) fun things we get to work on at Pure is researching and figuring out new ways to streamline things that are traditionally repetitive and time-consuming (read: boring). Recently, we looked at how we could go about automating the deployment of FlashStack™ end-to-end; since a traditional deployment absolutely includes some of these repetitive tasks. Our goal is to start off with a completely greenfield FlashStack (racked, powered, cabled and otherwise completely unconfigured) and automate everything possible to end up with a fully-functional VMware environment ready for use. After some thought, reading and discussion, we found that this goal was achievable with the combination of SmartConfig™ and VMware Cloud Foundation™.
Automating a FlashStack deployment makes a ton of sense: From the moment new hardware is procured and delivered to a datacenter, the race is on for it to switch from a liability to a money producing asset for the business. Further, using SmartConfig and Cloud Foundation together is really combining two blueprint-driven solutions: Cisco Validated Designs (CVDs) and VMware Validated Designs (VVDs). That does a lot to take the guesswork out of building the underlying infrastructure and hypervisor layers since firmware, hardware and software versions have all been pre validated and tested by Cisco, VMware and Pure Storage. In addition, these two tools also go through setting up these blueprints automatically via a customizable and repeatable framework.
Once we started working through this in the lab, the following automation workflow emerged:
Along with some introduction to the key technologies in play, we have divided the in-depth deployment guide into 3 core parts. All of these sections, including product overviews and click-by-click instructions are publicly available here on the Pure Storage VMware Platform Guide.
Deploy FlashStack with ESXi via SmartConfig. The input of this section will be factory reset Cisco hardware and the output will be a fully functional imaged/zoned/deployed UCS chassis with ESXi7 installed and ready for use with VMware Cloud Foundation.
Build VMware Cloud Foundation SDDC Manager on FlashStack. The primary input for CloudBuilder is, not ironically, the output of the work in part 1. Specifically, ESXi hosts and their underlying infrastructure, from which we will automatically deploy a Management Domain with CloudBuilder.
The last section will show how to deploy a VMware Cloud Foundation Workload Domain with Pure Storage as both Principle Storage (VMFS on FC) and Supplemental Storage (vVols). Options such as iSCSI are covered in additional KB articles in the VMware Cloud Foundation section of the Pure Storage support site.
Post-deployment, customers will enjoy the benefits of single-click lifecycle management for the bulk of their UCS and VMware components and the ability to dynamically scale up or down their Workload Domain deployment resources independently or collectively based upon specific needs (e.g. compute/memory, network and/or storage) all from SDDC Manager.
For those who prefer a more interactive demo, I’ve recorded an in-depth overview video of this automation project followed by a four-part demo video series that shows click-by-click just how easy and fast it is to deploy a FlashStack with VMware from scratch.
Craig Waters and I gave a Light Board session on this subject:
And this is an in-depth PowerPoint overview of the project:
Finally, this is a video series showing the end-to-end process in-depth broken into a few parts for brevity.
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?
