1:01:38 Webinar
Ask Us Everything About ActiveCluster for File
This month we’re diving into ActiveCluster™ for File and how the Everpure Platform delivers synchronous file replication as a native capability.
This webinar first aired on April 3, 2026
The first 5 minute(s) of our recorded Webinars are open; however, if you are enjoying them, we’ll ask for a little information to finish watching.
Click to View Transcript
We're live. Hey, good morning and afternoon to everybody. I'm Don Portas, you know. I'm Technical Evangelist here at Everpure, and welcome to another Ask Us Everything that's going to cover a topic that has been brutally hot since we first shipped files for FlashArray back in 2023, as I recall.
Today we're gonna talk about ActiveCluster for File, and like I said, it's been the hottest feature that everybody has been asking for since we released FlashArray files back in '23. And today I'm definitely upstaged by our guests today. I've got Russell Pope and Quinn Summers on board.
Russell clearly has a better beard than I do, and his claim to fame best-dressed guy at Pure, as you can see with his suit and quasi ascot, actually, I think, Russell, is the fact that he was the guy behind the blog post that I put out last year about scaling FlashBlade to 3.8 trillion objects. It was a incredible genius work on his part.
But the good news is, is we've got Russell today. We also have Quinn Summers, who has a much better voice for radio than I do, so he will have his buttery smooth tones in here as well. But guys, thank you for joining, chatting with us really quickly about all of this Active Cluster for File stuff.
Russell, I'll kick it over to you. Introduce yourself, tell your s- tell everybody who you are, what you're doing, and, you know- Yeah what you're hoping to do today. Well, thanks for having me here. My name is Russell Pope. I am an unstructured data specialist here at Pure Storage.
I've got an extensive background in systems integration, so I like to, tinker and play around with, all kinds of stuff. I build a lot of little projects to, make my life easier here at, Pure and, help solve customers', problems. It's been, been a great ride so far.
Awesome. Quinn, it's over to you, and I gotta say, Russell has a pretty nice voice too, so good luck- Well, thank you, Russell keeping up with him. Yeah. Well, yeah, thank you for the kind words. My name is Quinn Summers. I'm a Principal Product
Manager here at Everpure. I've been involved in enterprise storage for, ooh, boy, a quarter of a century. When I joined, I had hair, now I don't. I'm so proud to be wearing orange and talking about ActiveCluster for File in our, Enterprise Data Cloud today.
I have a similar joke to yours, Quinn. I always like to say, "Don't let the gray hair fool you, I am old." So you know, it, the hair goes when you're in an IT position, except for Russell, who apparently So- Quinn, kick it off, man. Sure. I appreciate you guys being here. Okay.
So I wanna set, the stage, by sharing just, four slides, and then we'll go of like the open, conversation format. The, we are talking about ActiveCluster for File. ActiveCluster for File is, it's not only a business continuity solution, but it's an integral c- component to how we envision that businesses manage their data going forward.
And what do I mean by that, is that, high availability has changed, right? Business continuity, requirements have been around for applications for a long time, but what we're finding out here is, is that data mobility is, is even more essential. As product life cycle management, you know, occurs, during application deployments, let's say an application becomes really, really popular, and it needs more performance or more
capacity or a different aspect that maybe the current architecture or platform doesn't have. Or maybe it becomes not as popular as it was before, and you're running it on dedicated gear, and you wanted to sort of move it down the stack to something more efficient, you know, with a little longer latencies or a cheaper profile for storing data over time. And so it's not about just high availability, it's really about can we manage application
data sets via policies, and can we policy actually affect autonomous actions on the data set? If I have a service level objective or a service level agreement for, a throughput on a application data set or a w- a RPO objective or RTO, our overall goal with the Enterprise Data Cloud and Pure Fusion fleet management, the, is to allow business level objectives to be
translated, you know, from more or less natural language that you're specifying with file presets, and then being transformed into a workload that, that presents itself that you can backup, copy or move. In this case, we're introducing the capability to synchronously mirror but also the file data and config data as well.
And I'll go into a little bit more details about what that means. Just to talk about these slides, we've seen other, competitors, you know, develop HA solutions out there that are usually We've seen them develop sometimes synchronized file mirroring solutions between pairwise HA pairs, you know, one-to-one.
And, and then there's challenges there. Does it, the right gila- granularity failover? Like, does it match the, the application data set, or is it, you know, restricted to a larger group of storage resources that is a wrong sort of mismatch in, between the application data set? I'll give an example.
If you have a OL- OLTP database, like high transactions, it's, you know, you want This is maybe a payment processing system. You want it to be up all the time, otherwise you're not collecting money. I- if that granularity of the application is only, say, say several hundred TiB, and your failover domain is the entire data center or a really large portion that's
100 terabytes, but even more, that to, to s- be, like, imposing archite inefficiencies across a business level objective that you wanna achieve. Mm-hmm. And so with our introduction for, for, Active Cluster for File, this is our policy-driven, right, autonomous, solution, right, for application data sets, that provides connectivity to the data regardless of what's
happening on the underlying hardware. So arrays can fail, the, individual connections can fail, and the customer still has access to data.The, ActiveCluster for File will support NFS v3, NFS, 4.1, SMB2, SMB3. We also support SMB 3.0, with continuous available shares.
And so, you know, applications usually retry their IO that they issue. But even if you're using, like, a user home share and you're using ActiveCluster for File, and you're using CA shares, and dragging and dropping from a Windows File Explorer, if for whatever reason one side of the data centers, you know, the, you don't have re-drag and drop the file because that operation is part of the CA shares.
We do the lock, lock replication across it. Okay, so the, I just wanna paint a- another picture of a visual. Again, we, we see other competitors out there have synchronized mirroring solutions, sometimes for file, sometimes they're, they're older. The challenges on here, again, is a between granularity, and not an
basically policy-based management. And, and so, each deployment of high availability configs becomes like a special or a 1touch. Maybe site A has entirely different infrastructure and hardware than site B. And the teams between site A and site B need to learn different, you know, operational run
books to actually make that failover happen. And so we think, across enterprises at scale, when you're managing hundreds and petabytes, intimate knowledge of individual deployments of hardware isn't very practical and doesn't lead to consistent business outcomes. And so if you can begin the journey of managing your application data sets by
specifying the policies, the business requirements around that data set, and then have those requirements dictate where that data set is, how it is accessed, and then inform you if there is service level agreements that are not being met and then, you know, automatically mitigated, that is the world that we are driving towards. That is our vision of the Enterprise Data Cloud.
And so at the end, like, if you've deployed and you embraced Pure Fusion fleets and you're managing programmatically, you know, hundreds of FlashArray and FlashBlade, you know, all together, and you look at sort of you have, policy definitions of application workloads, they can float or move dynamically across your entire fleet. They can be across different modalities.
So o- on the bottom, you see across edge or on-prem or cloud. We have the ability to do ActiveCluster for Block today in between on-prem and then the cloud-based version, right? So, and w- we expect to expand, capabilities over the fullness of time to include ActiveCluster for File as well.
ActiveCluster for File, again, will be released in two months, is the first And, and I'll stop here, for right now. I know I've been monologuing for a little bit. Yeah, Quinn, that's, that, that's, that's good, good stuff. I guess, what would you say is the secret sauce that makes it special, right?
I mean, you mentioned, like, policy-driven for things. Yep. Like, what does that practically mean for, for folks? Well, so, I think our policy management is, is within Pure Fusion file presets or of our Pure Fusion file presets that we can see. The policies start translating into what is a performance requirement, what is your backup requirement.
It's trying to take sort of how, owners view requirements around their, their application data set and translate it into a simpler set of words, right? That then is automatically maintained. And, and so we can see, service level agreements as part of our EG1, you know, contracts.
If you buy this, you have this amount of performance, you have this amount of capacity. And we really wanna give that sort of, feeling of, of management across your own fleets, right? That, that sort of capabilities. And, this is also something that, that we're super proud of as we're advancing.
We introduced Fusion a while ago. We've hit, you know, I think over 500 Pure Fusion deployments. We have expectations of order of magnitude greater in the year coming. If w- we start looking at the ActiveCluster for Setup Wizards, for, for, for File, they're fully Fusion enabled and encourages you to use Fusion to begin with, otherwise
you're managing the arrays. We don't want you to manage the arrays. We want, we want you to manage the data. And in that policy approach, I think, we, we've seen maybe suggestions of it across different organizations that may not be Everpure, but it is our, our commitment to actually making it real that, that excites me.
Um- Yeah. Yeah, and I think one of the things to inject here that you both have touched on that I think is really powerful, and we talked about it before the show too, was that you could look at ActiveCluster for File as just a survival tactic, right? Like a typical HA, thank God it's still up kind of thing.
But what you're talking about, Quinn, as well as you, Russell, is through policy, through Fusion, through all of these things that we're talking about, is helping the folks who are in the trenches managing into this and maybe accountable to SLAs to realize and potentially actually support the business objectives, the experience that drives the business objectives, right?
And that's a gap that's been there Forever, basically, right? And I think it's because traditional have looked at this as simply a survival technique, like we talked about, whereas saying, man, data portability, like you Quinn, when you're managing hundreds of petabytes, you really do need to start thinking in terms of policies and SLAs that align with business objectives and ultimately,
are you helping the business move forward, right? Yes. And this is how it happens. And, and that I think is one of the fundamental challenges of other businesses as they have played with or toyed with ideas of SLA management or policy-based the, we've seen some competitors' products out there dabble with the idea of SLAs or SLOs,
and they release a product, and then it dies on the vine for whatever reason. They either have an organizational where their attention has to be split other emergent thing that requires that sort of data management aspect to, to fall off the vine. And, that, that's why I'm so encouraged about our approach here, to the Enterprise Data
cloud.Is that, you know, e- every developer has a rule that has, has to have Fusion enabled. Mm-hmm. We're 100% committed to making this vision, be real. And then that's also another thing I do wanna mention. As we're releasing ActiveCluster for File, within the end of the May timeframe will be
our first, you know, release of the functionality. It will support full protocol, so that I mentioned. It will f- support automatic failover. It will support some other data management capabilities like, controlling via quotas, the, you know, managed directory quotas, the amount of capacity you can put in there.
But we're going to have a series of, of, of, you know, releases throughout the calendar year that further enhance the functionality. So you can envision sort of like rolling thunder. In the beginning, just like we introduced ActiveCluster for Block, in 2017, w- we would take a sort of s- a fairly conservative approach.
So be able to configure one realm, with the file systems and servers in there, and then mirror that. Shortly after, within two months, you'll be able to, you know, mirror up to five realms and have multiple storage objects And then throughout the rest of the year, we'll see a lot of the 610 functionality and the 68 functionality, like user and group quotas or QOS or things, come into play.
And so I just wanna set expectations. We're super excited about where we're going. We have a lot of things that are just in the back end of testing. We're finishing our beta tests, right now with our, our customers for ActiveCluster for File. And then once we release it at the end of, May, the, for our first TA release, folks will be
able to use it, and then we'll just grow the functionality afterwards. And, and so some of the things I'm talking about fall into the vision camp, but it's really important to talk about the vision, not just what happens on day one in, you know, the certain date in May, but what happens throughout the rest of the year, and then where we believe we're going next.
I, I guess we have the, the, that sort of the benefit of, hindsight, right? Like, we, we saw where everybody else had their missteps. We, we discovered nobody wants snakes in their data centers. And, like, we, we figured out- Right Pure Fusion, so we can do multi array management without needing extra tools and products to, to do that.
And, and, and one of the things that I was interesting is, just the setup, for ActiveCluster for File is it's, it's driven, from your, from your tar- re- from your source array, right? So you're just like- Yeah hey, I wanna set up an ActiveCluster relationship with another array, like, 10 miles away. And it's like, okay, let's go ahead.
We'll log in. We'll set everything up for you. We'll apply the policies and get everything mirrored up, and you're good to go. It's, it's mouse clicks instead of a lot of, you know, like, banging away on command line and making API calls or installing third-party software, et cetera. Mm-hmm. When- Yeah, that's a, that's a funny Sorry to cut you off, Quinn.
That's a funny thing you mentioned, Russell, because I, I've said this before and it's been challenged, y- you know, it's been in other vendors where I've worked at, you know, engineering will develop products, right? And they will put it together from an engineering perspective, and they will put it on the street with the assumption that their product is the only thing that
thinks about all day long, when in reality, the data center, you're wearing nine or 10 different hats. So you, you can't reeducate yourself every time you need to go do something, right? Mm-hmm. Wizards are actually okay. I'm not, I'm not against wizards.
As a matter of fact, I, I switched from managing Unix at the command line to a GUI when somebody handed me Windows NT 3.5, so I'm fine with that stuff. Sorry to interject there, but I'm very passionate- No, absolutely about making things simple. Absolutely. Yeah, so, so set up your
Russell is absolutely right. The, Fusion Fleet management means that you can manage the entire fleet, with remote operations through a single point, you anywhere within the Fusion Fleet itself. And, and that's, that may seem not terribly, you know, like, so who cares? But I remember, like, I had to burn a day, when I was setting up, you know, synchronous
mirroring solutions for different businesses a long time ago. I had to drive in between the data centers that were separated by a lot And so, like, if I messed up on cabling side, or I had to go and log in and then go back and forth, I, I didn't have the, the benefit of having a gigantic team at that point in my t- time of the career.
And it was- Yeah it was pain, right? And so the simple things as, as we have a lot of rich experience in the enterprise, trying to make operationally, things simpler. We know that our teams, the operational teams, are just They're maxed out. The, the environments are getting way more complex.
The capacity and the performance and the data that we're handling now seems to be growing, like, orders of magnitude exponentially over, like, the decades, right? Yeah. 15, I'd say, like, 20, 25 years ago, you know, I was m- managing 1.4, 4 megabyte disks. You know what I mean? Mm-hmm. They're floppy drives.
And now the, like, the idea of managing multiple petabytes is not beyond the pale. That's like a normal Pure experience. And so this is why the key of, like, how do we manage that scale via policy where you dictate what you want and it broadly applies to a large swath of objects or a large swath of file systems or a large set of app data sets, so you don't have to look
through them, is the only way forward. If you have a trillion objects or a trillion files, imagine how long it would take to list them, and if you have to find individual files then to do something with them, to backup them up or change permissions, I think that's unreasonably cumbersome. We, we, it's just, we don't work that fast, right?
So we have to depend on intelligent policy-based automation. I also think in the expectations of the world where everything 24 hour seven availability is expected from customers- Yeah from whatever service that they're, they're getting- Mm-hmm automation allows us to deliver that high level of availability without depending on people waking up at midnight to, you know, change around workloads or ra- you know, look
at alerts or, or something of that nature. And so one of the other things I always keep in mind as we're, you know, looking at developing new solutions going forward is how do we make a admin's life easier? I hated waking up on weekends. I hated burning family time- Oh, yeah on holidays, right?
And so if we can do non-disruptive operations and, and you can upgrade at any time during peak hours, and you don't have to worry about, like, like, the, the logistical difficulties of trying to do off hours, this is also part of our Fusion Fleet. You know, this is part of our autonomous policy-driven management and making sure that we have a strong end user story.Yeah.
Well, the good news is we got Sorry to cut you off, Russell. We, you guys can both jump in. We already have the questions coming in. Yeah. And this is, this is good stuff, right? Cause we've triggered something out there, which is great.
Cause I know you're gonna get under the hood and talk a little bit more about it. But from a, from a high-level it's probably the best way to start, is Jeff Brier, you know, he's interested in Active Cluster for Files as a replacement for NetApp SM- SVMDR, right? And y- you know, what does this look like from a design conceptual perspective
of how it fails over namespaces and things like that, and then we can get into some of the other questions that are starting to flow in about the mechanics of it all. Yeah, sure. Okay. So, let's, address, I think the first question was compare and contrast SVMDR and namespaces. Like, how, how does one solution look versus the other?
Yeah, client re-IPing as well. Like, the client- Yeah can't go to the other network, right? So. Oh, okay. Excellent. All right. So, w- ActiveCluster for File will support sort of two generic deployments. One, in which each center of the stretched realm, we're introducing I mean, folks have
already used it, but we're introducing files in the realms. Realms is the data management container that will be stretched, just like ActiveCluster for Block used the pod to stretch, we're stretching a realm. We use the stretch term to be like a verb that says, "Hey, I'm mirroring your data, I'm mirroring your configuration information." The two deployment scenarios I was talking about,
we either envision a shared L2, broadcast domain, like a Ethernet broadcast domain, where you have the same subnets on either side for your virtual interfaces. So you have, like, 192.168.2 over here, and you have the same subnet on the, you know, other side. In that scenario, failover's automatic. If, if, if one side craters, then, clients have sort of full connectivity to both, you
know, to the same subnet. There's no disruption. Clients don't have to remount. Clients don't have to, necessarily reissue, reissue IO that they've already been acknowledged. And so nothing changes from that perspective. File handles will change, will, will remain the same.
They won't get stale, FS IDs. It's, it's seamless from that perspective. Th- we do also support, because we know customer configurations differ from, from their data centers for a variety of reasons, that not everybody has a shared L2 network, right?
A broadcast domain across several hundred kilometers or several hundred miles. And so that instance, you will have different IP addresses on either side. The file system or file systems will be mirrored. They'll have identical data in it, but the protocol endpoints on the other sides can be differed.
And so if the clients on Site A need to access Site B, then there may be a disruption of service. But we s- we support both. Um- What When you say disruption of service, what, what do you mean? The time for the client to be redirected to a different network? Or what, what are the specifics?
If, if you think about Scenario A where we have, like, stretch layer 2- Right we can do things like SMB CA, so it's totally transparent, because the IP address- Easy enough, right we're talking to doesn't change. But when the IP address on the other side does change, the data is synchronously replicated, but I have to figure out a way at that point to redirect the clients to the new DR target.
A new one. Yeah. And so that could be, like, a DNS change-out or something like that, or, or, or remounting or reconnecting to those, those shared resources. Um- And, and usually though, usually in, in the scenarios where the different sort of subnets exist on either side, there's application servers on either side that are
either, are writing or reading or accessing it. And, and the failover, the data is synchronized. It's already there. And if the application is already up and running and accessing those exports or has, you know, have access to it, then, then in that sense, you know, there may not be disruption in the storage services.
So, so it depends on what the application setup is. Yeah. And it's also one of these things where it's the nature of networking itself, right? There's, there's no magical fix to get a client to go to a different network, right? It There's no intelligence in the system that automatically knows as a client where it needs
to go. Now, y- like you said, you can- Mm-hmm you can kick off DNS redirects or something like that- Mm-hmm. Yeah but obviously it is what it is as far as that's concerned. And, talk a little bit about the interconnect. Sure. What's your latency in all of that stuff? Yeah.
No, good question. Okay. So, our ray links, that we support b- today between FlashArrays, are, are, no changes. And so for replication, for either synchronous replication or asynchronous can use Fibre Channel as your transport, or you can use Ethernet as the transport. Doesn't matter. In terms of latency or distance
they will be identical to what we have for ActiveCluster today. So that's 11 milliseconds as the round trip time, sort of boundary. Now, I wanna bring this up a little bit too. So we know everybody's networks are a little bit different and, and we're poking at this a little bit more. So there's been studies mostly focused around
film about, like, human visual acuity. How What is the smallest interval of time that we can detect changes for? Right. And, and there's some suspicion that we can't actually detect changes, like, under 11 milliseconds. So, hey, if you're worried about a slow app, 11 milliseconds does matter.
But if we translate it into, like, frames per second from movies or whatnot or, like, like, what people try to idealize to, we may have the possibility of going to longer distances, and it may not affect performance of the application from a material way. And so while the, the WEKA, we have the cutoff at 11 milliseconds right now, but instances where your link is longer, please, please, please let me know.
We're really interested in seeing what we can do there as well. To Don Poorman's, earlier questions about, like, is there any magic stuff capable, if we look to the networking routing side, technologies that really help to try packets to go from one place to the next. Some of these technologies are already used in FlashBlade, and over the fullness of time we
expect some of these to come over to FA as, as the code base becomes more and more common. And, and so, right now we'll, we'll, the mechanisms of, of saying, "Hey, this IP address is now associated with this MAC address, and it's associated with these physical sub interfaces," will, will be, you know, handled through a mechanism that looks like reverse, address resolution probe gas b-Protocol broadcasts like ARPs, or, or things
of that nature. It may change in the fullness of time and make it easier for, for different network connected- Nice, nice hint. N- ni- nice little hint there. Thank you. Hey, Russell, let's get you talking a little bit. You know, practical application of this, you
know, Sean Flowers asked, "You know, if I have file in place right now and I wanna roll this in, how does it look like? Is it gonna disrupt things? Is- do I gotta r- rebuild my array from scratch?" All of that stuff. Yeah. Right. So there's a different answer depending on
what time of year you want to deploy. Sorry, Russell. No worries. I, I, I, I was, I was ready to throw out the same answer and it- Yeah, then go ahead, man. Do what you want, do what you want. So, so at release we're gonna create a realm that's self-contained with its own set of
servers and file systems and things like that, and the intent would be data into this new realm that's doing ActiveCluster. And then down the road in the fullness of time, to quote Mr. Quinn Summers, we will support, brownfield deployments, when, when we think we're ready for that. Yeah. And Quinn, I don't know if you wanna add
some color to that or Yeah. Yeah, yeah. So, so, so you're, you're absolutely r- right. When we release the code, which is, you know, we're, we're aiming at 6.12.a, you first release line of STaaS the 6.12 feature line, we require brand-new file systems to be created. We have a lot of new data structures
associated with the file system to keep track of mirroring and everything like that, and so we haven't implemented the mechanisms to add that additional stuff, the additional metadata, to existing file systems running 6.10 or before. And so, part of our rolling thunder, in the very beginning, new file systems created 6.12 and beyond, within a realm you'll be able to stretch it and mirror it.
This is, eh, it's not ideal, but it is our beginnings walking point. Shortly afterwards, then we'll have releases that support, existing file moved in, you know, into the realm, and, that, that, that you don't have to do a, a client-side copy operation or, or whatnot. And, and so this is also quite similar to how we introduced ActiveCluster for, for Block.
We begin with a sort of a narrow set of functionality. We, we have some soak time to make sure that our integrations are working really well at that scale, and then we broaden the aperture as it goes. And that limiting of the aperture in the beginning to new applications is on purpose, un- unfortunately, so But, it will fairly quickly after we release, i- in
Yeah, we're known, we're known for being pretty aggressive on stuff like this, so, so that's, that's a really good thing. Yeah. So- And just a question- And just to emphasize- Yeah new file systems only in 6.12, 6.12 and after. What about, so, you know, it, and then I assume then, that applies to snapshot policies
and everything else, right? Like, yeah, we're gonna have to pull you into a new experience and reapply snapshots and everything, or are snapshots still within the realm? No. W- when we support brown- brownfield, policies associated with, w- with the file systems that move in, will, will be supported.
Same with snapshots. You don't have to delete snapshots or like that. The, snapshot policies, so the realm is a container. All the policies in the realm would be replicated across the realm itself. And so, the realm also acts as sort of like a policy namespace in some regard.
So if you're in realm one, you could have a different set of policies. If you're in realm two, you maybe have an entirely another set of different policies, and that differs from your FlashArray set of policies, too. You'd be like, "Well, that's sort of Why?" Well, we envision realms as potentially a mechanism for multi-tenancy.
So you have Coke and Pepsi, and one is in one and the other one is in one, and they have different policies. But, but, as the pol- as the realm, is intended to be mirrored, you know, synchronously and, and then, via other mechanisms or asynchronously a- as well in the future, we want all those policies to flow with the container, to go wherever it is.
Makes sense. Yeah. And, and so this would simplify, disaster recovery. This simplifies our business continuity, and, and it's essential, providing RTO zero and RPO zero. We have to have config data mirrored, otherwise we can't provide that access. Perfect. And, and Russell, I'll, I'll throw you into
the mix here. Let's talk about fail over fail back, right? Yeah. What does it look like, talking about mediators and where I'm accessing and what gets- happens when it comes back online, all of the usual things that somebody looking at this wants to, you know, understand. So, once you've got the ActiveCluster set up, fail over, like, say, we'll just assume layer
two stretch for the purposes of brevity, right? That fail over is automatic. And then when the primary site comes back, we'll begin the process of bringing the two s- sites back into, in, into sync with And then at that point you can, you can opt to fail back, or you can just wait for the
secondary data center to fall down, and then, you know, repeat the process. And then, and I, I did see a note on the, the DNS stuff. If it's not a layer two stretch, the DNS update today will not be automatic. But that being said, everything we do here at, Everpure is API first. Right. And so it's pretty easy to build some automation to kind of take care of that.
I actually just did this for another customer, literally yesterday, being and SPNs and things like that for, more automated fail over for, for, for their, for their Everpure platforms. And I feel like I missed one thing that you had asked about in your question. It was, it was fail back.
Talk about the mediator, because that's an important component as it relates to the time delay in failing from one to the other, right? Because it is a huge differentiator, how we're managing it, right?Yeah. So, so let, let me set the stage. I'm not sure if everybody's familiar with what the mediator services are or, or what function
they do. Whenever you're mirroring data and you're accepting writes, you know, or the of writing on both sides or divergent of, of the file systems, the, the assumption is that you have a healthy network connection between the two, and you're mirroring the data faithfully. But if the, if the network that is for mirroring the data between the both data
centers suddenly gets partitioned, you have an unusual opportunity. You have two complete copies of data on either side. You have application servers that can write data to either side. And if they do, all of a sudden you've diverged. Humpty Dumpty has come apart.
There's not a It's not a clone or a mirror. Yeah. It's like two divergent file systems. Mm-hmm. And usually that's bad. Putting it back together and merging is a pain in the butt, to say the least. So to avoid this, to avoid split brain scenarios where you allow a mirrored, you know,
a, a situation to allow dual writers without talking to each other, the strategy is to employ, deploy like a witness service or, or what we call the mediator. Right. In other, deployments or other, other s- synchronous solutions from competitors, a mediator is, is a common approach as well. But they typically require you to, to have this witness, you know, deployed on a v- its
own virtual machine that then you have to maintain and patch and worry about high availability for the mediator. And what the mediator does, in the Pure, is that if there is a network if the Array links, if the replication Array links between the Arrays are severed, both of them, right? There's n- there was redundancy on all the
layers of, of our, of our solutions here. Then, each FlashArray system reaches out, our mediator service that we host in the cloud for everybody, so you don't have to maintain a VM. And it's like a, it's like a race. Whoever, whoever gets to communicate to the mediator first says, "I get the write token.
I can, I can process writes." And if the other array gets to it second, they're like, "Nope, okay. You don't have the baton." and we find that a remarkably easy way to sort of make sure that we're providing storage services, even if there's a network partition between the array links. It's easier operationally to maintain.
It's sort of like something you don't have to worry about. We do have options to support it on dark sites. So if you're a customer in three-letter agencies- Right, right and you can't report telemetry anywhere, we have these services for you. It's just, you know, you gotta maintain them.
The other thing I want to say, and this is unique, it, it sort of speaks to some of our philoso- our philosophical approaches for, for business continuity, continuity solutions, is that in, in older, l- legacy solutions from competitors, sometimes we would see a logic choice that said stop fail. If there was a partition in the, the connectivity between the arrays that they were
mirroring and they couldn't get to the mediator, they were like, "Nope, we're not going to allow any writes anywhere. We don't know." Mm-hmm. Until there's a human in the middle that says, Site A is the, is the one, everything fails. And I don't know about you, but I'd get anxious if I go, like, put my ATM card
into the bank and, and it just doesn't work. I'd be like, "Uh-oh." and so, uh- we've, made a lot of conscious decisions. In the case where the array, L-replication links are not available to transfer health information between the FlashArrays, and you can't get to the mediator, even ahead of time when you've created a stretched realm, there's a, there's an agreement between both arrays.
If one cannot communicate with each other, who wins? And so the result of that is that in a mirrored solution where you have application servers on either side providing these services, is your application doesn't stop. You have one side failover, you have a cascading series of, of events. Your array links are down.
You can't get to the mediator. There's another problem on a network somewhere else, and your application is still running, right? And, and that's It's, it's subtle, but, but that's really important. Like, if you're, you have a mission system, you really, really, really want it to
be online all time. Like, like, no, no lying. Yeah. Yeah. And Russell, Quinn kind of moved past it pretty quickly, but can you clarify specifically the mediator service, right? So it's there, right?
And like Quinn said, we usually host it through Pure1, but if you don't have that, if you're not allowed to do that, what does the service look like? Is it a virtual machine? Is it W- what, what does it look like, Russell? I believe it's a virtual machine that gets deployed. That, that's one of those things where I probably end up deferring to Quinn on,
honest with you. Uh- Oh, yeah. Sorry please, I'm just making- I pulled you in. I wanted to pull you in. It's, it's, it's a Linux. It's a, it's a Linux machine. It could be a- Okay, cool virtual machine, could be bare iron, doesn't matter. Linux.
Yeah. Yeah. And like I say, it's just, it's just there to make sure that, we don't, accidentally make both sides suddenly think they're the master. Yeah. Yeah. And, and, it's a RPC call using, HTTP, as a transport, right? Mm-hmm. So you don't have to open up anything in your firewalls.
It should just work. Yeah, and it all just talks to the management interface of the arrays, right? Mm-hmm. Yep. So that's fairly straightforward. Talk to me a little bit about, the, the new antivirus stuff that's come out. What does that look like related to this as well?
Yeah, sure. We're, we're excited about supporting our ICAP interfaces for AV scanning, within partners, right? So this means that when a client request comes in, the, it would take some small information, you know, around the file that's being accessed, put that over into a AV scanning pool of servers, to do load balancing and ax- answer back to the FlashArray.
And then if it sort of examines the piece of data that's being requested and says, "Hey, it's cool. We don't see any viruses or malware in that signature," then it allows that I/O to go back to the client. This is something that, that we're excited about being delivered. This is also one of the pieces of capabilities, that will come later
towards the end of the year. So, so not a re- not initially in the v1 side. So and the general mental model is, we had a lot of fantastic file function functionality in 6.8 and 6.10. Lots and lots of performance increases, user and group quotas, the audit logging and
security logging, our AV scanning coming into play. We have, now within, 6.10.5, MD Clone, right? Like, fast, efficient- Yeah cloning workflows for app dev tests. The majority, the bulk of those advanced data management features will come toward of the calendar year within realms to mirror.
And, and so if, if this functionality is really important to you, I just wanna give a heads-up, it will not be there within the May release.Let's talk real quickly about workflow, of something that you just talked about, especially with ICAP. So a file gets accessed or a file gets dropped on, and then the ICAP call goes out, right? Mm-hmm.
The file is looked at and said, "Yeah, it's fine." Mm-hmm. Talk us through how the replication and the ACK comes back, right? Because there could be potentially, if you're on the primary, right, you put your file there and the ICAP is working- Mm-hmm you're in a sit- you're in a situation where it hasn't been replicated yet, or has it?
Does it get replicated, then come back and do the ICAP? Hopefully that makes sense, because- I think, yeah I can hear people's gears turning. Yeah. So, so, o- one of the differences, and then this is, again, part of rolling Thunder over, you know, extended, time periods, is that, one of the differences with an ActiveCluster for File and ActiveCluster for Block is in the
first generation of when we release a Active Cluster for File, it will only accept writes on one side. O- one side will be only active. The other side will act as the insurance policy for that automatic failover. And so from that perspective, the side that is ActiveCluster, or its leader if you will, will most likely be communicating to a local AV server.
That's the most efficient. You can have one across the data center, but it's better to have it locally. And then that would be processing the writes, and that information would then, then, you know, be synchronously mirrored over into its partner. And then if a failover scenario would happen, I think we'd either have
two potential scenarios. Either we depend on a AV farm just in one data center, or we have two AV and it just uses the one locally. Um- Mm-hmm I don't think anything gets reset across failover. We, we, we persist that information.
Yeah, but, so, so we're excited about the integration. What, what, what, right, right out of the gate, what, what, what are the AVs CrowdStrike or w- what, what, what are, what's the list? Do you know off the top of your head? Yeah. Let me, let me pop it up so I don't
I want to say- Just somebody, somebody drop that in, which it does make sense, obviously, what's there. I want to say Trellix and, and several others. There's a, there's a roadmap of partners that we're calling, and I'm, I'm, I'd let me, I need to look up which one comes first. We can, we can, we can revisit that. Okay, certainly. No, there's no need to go
digging it up right now. Yeah. Russell, I'm gonna, I'm gonna flip it over to you to give Quinn a chance to, to REST API his voice. Joe Klein came in with a very, very interesting question. Cross-model replication, does this work?
Can I do it on an X90 over to a C90 or 70 or something like Can I do that? Yes. I Quinn, quiet. Russell? Oh, sorry. No, yeah. J- just, just make sure you take into consideration your plumbing and, resource utilization.
You know, if your, if your, if your file is using most of an X90, uh- Mm-hmm then you probably don't wanna, you know, send that to a C70, right? But if file is a subset of your x90 and you wanna replicate to a c70, that's most likely fine. You shouldn't have any issues there. Yeah, and that's it, it, it talks to the point
that, listen, we're talking abstraction of function way above the hardware here, right? So the hardware is really just an execution thing, right? Yeah. The, the service exists above that, so like you said, Russell, if you're overwhelming your x with file and you wanna send it to a FlashArray//C, it might not be the Probably not the best thing, right? Yeah. But, into another question here, and I'm
gonna put both of you on the spot because it's been a question before, the cloud stuff, right? The Everpure cloud stuff, which used to be called Cloud Block Store and all of that. Are we eventually going to reach the point where our cloud functions will include file protocols? Boy, you guys are both quiet.
You guys are both very, very quiet. I gotta defer to Quinn on that one, for sure. Yeah. No. That, that is the, that is the vision, right? That is the vision that, that we, that I was hinting at in terms of that modalities. And hinting, or not hinting, I mean, we currently support, the, the ActiveCluster for
Block in between on-prem, you know, and the, the entity formerly known as Cloud Block Store. That works today, right? And so we want to make sure that the same data management capabilities that we're bringing to play, or that we've already prou- brought to play for customers who are, who've experienced the awesomeness of using block solutions on, on Pure, have the same
experience for file protocols. That's, that's the general strategy, right? There, there, there may be- So the idea is eventually, eventually file will end up in Cloud Block Store, correct? Like, that's our goal. Mm-hmm.
As of today, it's not, right? That's okay. Correct. That's right. Yeah. It's not there today, but it is planned, so that's, that's good. I like that. That, that's a tough one to answer, right? So let's talk about selective failover, right?
Is this an all or nothing thing? So if I've got all You know, let's got 20 realms stretched between sites, and the ActiveCluster fails or something like that. Is it assumed that all 20 are naturally going to come up on the other side? Cause we're getting some of those of control questions that people ask
Yeah about this kind of stuff, right? Yeah. Right, right. So, so in the future when we allow multiple realms to be stretched across different destinations, Russell's point too, the destinations don't have to be the same controllers. Um- Right and then failover would be automatic, and so you could go from
one FlashArray to X, right? Whatever the X number is that we qualify. And that failover should be automatic regardless of whether it's, you know, pairwise or, like, spoke and hub type stuff. The, failback is, is something that, you know, we would either have manual, manual,
intervention for, or policy-driven, right? Maybe in the future. Okay. Yeah. The policy is the thing, right? Yeah. So the policy needs to be set up to manage into that. And, and then just one thing to mention, like, like Russell already said this, but it's
really good to reemphasize. So we do support, or we will support This is the problem with product manager. I live in the future and we're talking product that comes out in two months. The, anyways, um-The, we will support cross-platform replication from Cs to Xs to XLs, et cetera. But the lowest sort of capabilities of the
platform that you're mirroring to will sort of limit the capabilities of the file system, right? So if your XL can push massive, massive amounts of really, fast, low latency file throughput, and you're synchronously mirroring it to, like, a lower C product that's slower, don't expect the XL, you know, speed to match that of the- Right C. You're going to be limited by the C's
capabilities of latency there. Which makes sense. Mm-hmm. Which does make sense. Let's talk use cases real quickly, 'cause I know- Yeah some people are obviously rolling through their head that this works great for corporate shares, it works great for group shares, and personal shares, and all of that stuff.
What are some of the more advanced things? Like, could I- Yeah possibly consider doing this for an NFS datastore for VMware? Probably not- 100% but it's worth thinking. 100%. So, so we are excited to have integrated solutions with our technical alliance partners, as we roll it out as part
of our Rolling Thunder. Use cases. So yeah, file shares is one, and, and I wouldn't discount this. Like, like, we've seen customers say, "Hey, we have extraordinarily, important output that represents hundreds of years of research that we need to maintain, otherwise our business fails," right? Yeah.
But, but that's not, that's not the majo- majority. Where I see, the primary interest in from, multiple partners and customers financial service applications. You know, there's some data around trading that seems to really benefit by mirroring across different locations for quantitative- Can't imagine why analysis or quant chops.
Yeah, couldn't imagine why. Financials, other financial services, even banking, applications, payment processing systems. You know, these are, these are mission-critical, highly available, data sets. Transactional processing stuff, whether it's mail or whether it's actual, you know, point
of sale, systems potentially could, could be deployed on here as well. And so there's, there's really no limits per se. The, the key is, is matching what type of advanced data management functionality that that application data sets needs to, to when it comes over time. You know, it's like basically do you deploy during summer or do you deploy
is- So tell me how we test it. That just came in. Go ahead. Real time, man. How do we test it? Oh, that's all right. Russell, Quinn, you, you're quiet. Okay, sorry. Russell, go ahead. Well- Russ- Russell's the,
Russell's the practitioner. I, yeah, I haven't had a chance to kick, the tires on it in a lab yet, so I'm waiting for Quinn to give me, give me the keys to the kingdom. So, you know, Q- Quinn, can we, can we break off a copy of the remote, file system and, attach it to an isolated test network?
So we are, we are, in the process of out test drive instances, with a guided for everybody to kick the tires on a virtual instance of ActiveCluster for File. We have some, EBC, EBC centers that have advanced copies of the code in there for demoing from our principal technologists right now. The, and, and then we're two months away from the code being available for everybody to use
too, right? Just- What we were specifically asking about- various conditions can test though is testing failover, though. Oh. Oh, yeah. So not, not kicking the tires on the code- Oh, okay actually testing failover. I've got it. Yeah.
I want to try it. All right. So- Yeah so this is, again, one of the things that was unique to Pure. It's like I come aboard, and, and while ago, and they said, "Okay, how do we test failover? What is your secret command to test failover? I'm like, "We don't have a secret command.
We just pull the plug." Like, "Whoa. Why?" I'm like, "Well, because we think in the real en- environment, failures appear as cable pulls. They don't appear as a privileged level command to shut down- Correct a process or hup it or something like." And, and so our failure conditions during testing and our test plans
for, for our beta customers are very similar to how we do HA testing, today. Cable pulls. Pull Ethernet cables, pull array links, pull, the connections to, you know, your outbound mediators, pull power, pull- Trust me, bro the controller out. Trust me, bro. I think, I think one way to look at it is if you think of it, of ActiveCluster for File as,
like, going from a two controller solution to a four controller solution. Uh- Mm-hmm. So your, your, your, your validation is that if I lose a controller, then another controller's gonna take over, and if that controller goes away, well then another controller's gonna take over. So it's, it's kind of like do we test, just a single site with two controllers, uh-
Right or do we just, is the failover imply that it's gonna work? I think where those, those test bubbles really come into play is when you're asynchronous replication of the remote site with, like, Active DR- Mm-hmm and we need to periodically bring that up and run through- a workflow to bring the business back online inside of a test bubble, where this just like a hardware failure, it's
hardware happens to be a building as opposed to a controller. Yep. Yeah. And what's funny, what's funny about what you just said, Quinn, and what you just supported, Russell, is I pushed a blog last WEKA that talked exactly about what you said, which is why doesn't FlashArray have a power button?
Because the way you power it off is you pull the plug- Yeah because we have baked our error correction and all of our disaster recovery usage of code right into the usual stuff, right? We, we take reads from parity stripes and stuff like that. And, and, you know, to your point, this should be working regardless, right?
There shouldn't be a magical bubble you have to put everything in, because the real test is, wow, I just lost power, right? So I, I think that's an excellent way of positioning it, Russell. Yeah. And, so just expectations. Cable pulls, like, removing Array links, array links, right?
Or, or controller failovers. It should have a very similar experience to local HA failover. It, it should happen, you know, like, under 10 seconds typically. There are s- s- scenarios if you start pulling all of the sub interfaces or, or, or multiple of them. There, there may be periods of time
where that, you know, failure detection route as we're trying to figure out what's going on lasts longer than 10 seconds. But in general, the, the expectation that we're setting up is, is that you should resume services in, in around 10 seconds or, or so.Yeah, that, that makes perfect sense. And just to clarify, when, when we are talking about failover, it's
level, right? We're not talking Array level, we're not talking folder level. We're talking- Yeah at the realm itself because that's what we ultimately stretch, right? Yeah. And, and the realm contains servers which have, they can be associated with diff directory domains, they could be o- associated with different o- LDAP domains.
That's where your policy configuration information is. That's where your networking information resides. Later on when we support, you know, more advanced features of different audit logging or security styles on it, that information is contained there. And you're right, it's all mirrored.
So these constituent parts don't fail over, it's the entire realm that is always available and on one side, or, or the other. Cool. What about visibility into all of this? Obviously, a- a- and, and there's a that came in that is less about ActiveCluster and more about visibility.
So Russell, this might be perfect for you as a, as a practitioner, is y- talking about file shares and, and data and all of that stuff, you know. Can I go to Pure1 and get a feel for what all this is looking like in an ecosystem as far as accesses and all of those things? Cause we've got, you know, file anomaly detection and all of that.
Obviously, stretching it across the realm would be great, but let's back into that's kind of fundamental to, to file in general. Yeah, I mean, you're, you're still gonna have all those same telemetry options available to you, right? I mean, at the end of the day, it's a file system in a server on a realm on a FlashArray.
It's just that now we've got some secret sauce and magical wizardry. We're bringing Gandalf in so that we have that- Yeah transparent failover, across multiple locations. So you'll still be able to pull the same reports and get the same insights from your data that, you would expect, in th- in this type of environment. Yeah.
I- in addition to what Russell has said, which is absolutely correct, if you guys are familiar already with sort of how Active Cluster for block looks like from a visibility perspective, if you log in, you know, to, to the GUIs and you look at the performance dashboards, especially the performance side, when, when a pod is mirrored or stretched, you know, as part of the ActiveCluster today, you'll start getting new lines of visibility
into mirrored writes, latency and, and other sort of, visuals around bandwidth utilization for the array link and what's happening. Mm-hmm, mm-hmm. And so we think this is, this is just important diagnostics. Once you start stretching a realm, you want to make sure that you can tell what the health is
of your array links, what your bandwidth utilization is like, how often you're writing on one side or the next, 'cause these are all components to say if something goes wrong wh- where to solve it, and, and not as a person, but programmatically where to solve it. So. Yeah. And, and from the perspective of you always get bitten by the thing
you didn't expect, right? Yeah. In, in all of this. Somebody did ask, and it, it's a really good one. Paul Bradley asked this, "Can we do it on any type of share?" Right? You said SMB, you said NFS, but what about multi-protocol shares that allow
and NFS in the same spot, right? It's, it's far enough removed, that, that, yeah, it's just, again, at the end of the day, it's a realm with a server and file systems, and then how you want to it's just the same. So if we're doing a multiprotocol share, that's gonna be affiliated with a file system that's gonna have an Active Directory or an
LDAP relationship with some kind of directory service. And it, it will just work. Yeah. Yeah, and, a- and I tell you what, it, it's, it's funny too when you say it'll just work because the chatter after we said, "Just pull the plug, man. That'll test it." That, that, that was a little sensitive, but it's like, it's kind of
the only way you really can do it, man. Yeah. I mean, good luck with all it. Be, be sure your networking guys are in the loop. And, and this is I want to be honest, this is one of our challenges for the test drive instances.
Like, we're pulling the plug and so how do we simulate that in the virtual test Cloud Drive sandbox? So. Right. Right, right, right. Yeah, that's, that's pretty funny. So I, I guess, Russell, you've been on the ground talking about it, and you've- Yeah
you've probably set it up before. What have you seen so far? And it could be the good, bad, ugly. You know, Quinn's right here. He's the PM. Give him some feedback, man.
No, I think, customers are excited, about this. I've been working with a lot of healthcare, organizations and even a couple insurance carriers where they're very excited for, for this feature to come to them, whether it's like PACS medical imaging or like- Mm-hmm financial purposes, things like that. Th- th- they're elated.
I mean, and even, even with some of the, initial limitations we'll have at launch, this is important enough to them that they're going to be like, "We'll, we'll adopt this, as soon as it ships. We're gonna, we're gonna get this on the ground. We're gonna start POC-ing it, and we'll probably have this in production, before we even get to the next version." That's, that's
kind of the, the, the consensus I'm getting from the field as I talk to customers about this, and I've been beating this war drum every day since the, since the public announcement was made. I was like, oh, 'cause I was actually in a meeting with a customer the day before the public announcement, and they're like, "It would be really cool if I could have transparent failover because my two data
centers are in the same campus, uh- Right you know, like 600 yards apart." And I was like, I had to hold my tongue until the next day and then I was able to send out that, that, that email. Now we can talk. Customer- Now we can talk. Here's some cool stuff that I couldn't tell you about yesterday.
But yeah, that's been my experience in the field so far. What's been, A- and I assume that y- because we are talking about file as the lowest level of the service here, everything that we talk about with file is still within play, right? Unlimited objects and, and all of the usual stuff, right? There's no, there's no limitation here, like, right?
It has the same, the same limitations as our file system offering today. Yeah. Yeah. So 4 million files per directory. I think 10 billion files per FA. The, 50 file systems, 5,000 managed directories, these, these are the same limits. In the V1 version on May, we may constrain it to one realm, one server, you know, a, a
fairly constrained footprint- Yeah then rapidly iterate and b- build out the m- more object scale, like from a server perspective and a realm perspective. But in inside the realm itself, we, we I do, I am not aware of any limitations that are lower than what we currently have for our file solutions. Li- so we're not limited on numbers of realms, number of file shares- Oh, yeah
of, you know, all that stuff or- Yeah. No, so the limits in the beginning around the number of realms that you can mirror- Yep which will be one in May- One and then we'll expand to five, right? And then- Baby steps and then, and potentially more than that. But we won't have, as far as I understand, we'll have the ability to support 16 servers
with the same realm. I mean, we support 16 servers per FlashArray right now. Yeah. We have some tunables that we maybe can make that go more. But w- I think it'd be unusual to have 16 servers in a realm. But, but from that perspective, again, we, we, not limited that way. So the limits I would focus on is in the very
beginning with V1, we'll have a single realm that can be stretched. We'll have the contents and policies in there that will flow, protocol support. We'll have, managed directory quotas so you can limit the amount of space that can be consumed. I saw a question of saying, "Hey, pulling the plug isn't great if I have multiple applications doing the same thing." I was
gonna lo- I was gonna bring that one around. Um- I love that one. Yeah. Go ahead. Go ahead. And, and so maybe another mechanism is, for data mobility, we don't shut one Array off completely, right? Data mobility is this fine granular application data set moving, you know, across
your, your, your, Fusion fleet. And that stepwise procedure looks like an inchworm. Like, it stretches and then it unstretches, and stretches and unstretches, right? And so the unstretch operation basically says, I have a data set now that I've mirrored across two locations.
My config is mirrored on both sides. I've moved it to where I want, and my clients are accessing it, and now I can and leave behind my other clients just fine. And so, you know, that's potentially one way to sort of think about ways to test, if I unstretch it, what happens to my clients on the unstretched side?
As, as like- Yeah one potential of saying, I don't want to fail my entire I have a whole bunch of stuff here. Well, you can always unstretch it. And that, that is key to the data mobility component that's happening underneath data mobility. When we move something, we mirror it first and then un-mirror it after it's been copied to
the new de- destination. Makes sense. That makes perfect sense. Well, guys, we, we are four minutes away from the top of the hour. I, I know you guys didn't think we would possibly make it happen, but I knew we get the questions flowing in as soon as guys started talking.
Quinn, I'll, I'll leave it over to you. Any, any final comments that you've got on this? Like I said, this is a feature that the, been bugged about ever since FlashArray for file came out. So it's great to see that it's finally out there, but I'll leave it back to you for any final thoughts. Yeah.
S- so in closing, I, I, I'd say, like, I'm, I'm extremely proud of what we're building and what we're gonna release within May, but that is only the beginning, right? It is the only beginning of our journey. And, and so, we anticipate, rapid advancements for feature and after we have the basics rock solid, right?
After they're absolutely solid. And, and so if your customer's interested in synchronous mirroring, maybe part of the two-step process would be like, hey, kick the tires when it comes out in May, start calling it, seeing what it does. Test the failover scenario, see what application integration looks like, set up,
ESXi and vSphere and, like, fail over and, and, and test it out. And then after everybody becomes comfortable with it, then, then look at the advanced data management features coming in towards the end of the year, you know? And, and maybe it's two-step. You call during summer, and you deploy during winter, right?
Or, or something of that nature. The other thing is always is, is Pure, Everpure is really proud to, to be agile, right? To, to make product decisions and our solution decisions largely based off of our customer and partner input.
And so if there's an area that we have missed in our plan of, of rolling out, you know, business continuity solutions within the context of, the Enterprise Data Cloud and autonomous policy-driven management of storage, then, well, I'd really like to your account rep, to your SE, to, to, to me, right? Eventually to say, "Hey, this is really important.
We, we, we would love to deploy ActiveCluster for File, but it's missing, you know, X, Y, or Z, and we won't be able to do that have that feature." And that type of your, SEs, your account reps, your FSAs, our partners is, is really important. It helps us drive and focus on, on what is the biggest value we can give to you fastest. So don't be shy. Kick the tires.
Yep. Check it out. access the test drive when it becomes, live available. We'll send out some notifications. And, and just stay tuned. Yeah. Yeah, and to, to your point, Nicole just put
it in the chat for everybody. If you do have questions, join Pure Community and throw your questions Quinn is in there, Russell's in there, I'm in there. Everybody who you've seen on Ask Us Everything so far is in there, and conversation going there.
Yeah. I also saw another question of like, "Hey, is there license cost associated with this? Is it really pricey?" Oh, yeah, this is a good one. And they're like, "Oh." Go ahead. Throw it out there. Yeah. No, this is a part of our normal functionality, so, you know, it comes
subscription to Pure1. Uh- Yeah in other words, it's free. Like you get access- There's no bill to the functionality as we upgrade, so. Yeah. Yeah, absolutely. Russell- Well- your turn, man. What are your, what are your final thoughts, man?
Yeah, one thing I just wanted to s- kind of echo what Quinn was, talking about. So if you want to have kind of a personal dialogue about, what ActiveCluster is and if it's a good fit or just want to learn more, have your account teams bring in one of our unstructured data, field solutions architects to come in and, chat with you, 1touch. And when we do launch the test drives, we're also more than happy to come and sit with you,
and kind of walk you through the labs, kind of give you that concierge approach 'cause we wanna make sure that, you guys have a good experience and that, you can get that feedback. And our FSAs, our field solutions architects, we have a direct line right back into product management to, bring that feedback home, so that we can noodle on it and, make the product better.
And, just wanted to say thanks to everybody for giving us an opportunity to, to, to yammer on a bit. Yeah. Yeah, absolutely. It, it's been a phenomenal conversation, as they always are on th- on this thing. Quinn, thank you for your depth of knowledge.
Thank you for your, your honesty and transparency. Russell, thank you so much for your the ground observations and, you know, the idea of how to think pragmatically about all of it. And, you know, I think to summarize what you guys just said, which is huge, is that, y- you know, we know we're in a saturated market with storage and people looking to Pure as possibly
being their vendor. It requires a level of trust. And the way Russell just described how we engage and talk about these things and how Quinn supports these conversations as a PM is everything for us, right? This is, this is how we build the trust and get more people over to us.
So we're not kidding when we talk about STaaS with an FSA, talk to Quinn, get on community, because this is exactly how we help you move away from the legacy mindset to the modern data management mindset. So, Nicole, if you want to throw up the Accelerate slide, I'll, I'll finish that real quickly.
To everybody out there, we're throwing this out there again. Accelerate is coming again as usual, June 16th through the 18th in Las Vegas World, of course. It's actually a really good venue. I like it. It's absolutely It, it's, it's very self-contained, it's very engaging, and it's extremely potent on the information and what
you see. So scan that QR code, get yourself registered, talk to the boss. Everybody loves Vegas in June, I'm sure. So head on out and see us out there. You'll probably see most of us there when you do. And again, thanks everybody for being on this Ask Us Everything About ActiveCluster for File.
Thank you again to Russell Pope and Quinn, and we'll see you in a couple weeks on the next one. Take care, guys. Thank you. Thanks. Thanks.
Russell Pope
Consulting Field Solutions Architect, Everpure
Quinn Summers
Principal Product Manager, Everpure
Don Poorman
Sr. Technical Evangelist, Everpure
Got questions about continuous file access and true mobility? Get answers.
This month we’re diving into ActiveCluster™ for File and how the Everpure Platform delivers synchronous file replication as a native capability. As file data grows and availability requirements increase, infrastructure teams need data mobility and business continuity that’s automated, transparent, and built into the platform they already trust.
You’ll get an overview of how ActiveCluster for File enables:
- Continuous file access during migrations, maintenance, and failover
- Simple setup driven by Everpure Fusion™ with policy-based automation
- Granular, workload-level failover control
- Zero RPO and RTO availability without added hardware or complexity
We Also Recommend...
Personalize for Me
My Updates
No updates at this time.