00:01
Okay, stop me if you've heard this before. Wait, you really can't stop me because this is a one-way video. But anyway, humor me for a second. There it is. It's Friday afternoon.
00:13
You're furiously working on a report for the boss who's breathing down your neck and absolutely has to have it by the close of business that day. And you're madly typing away, and suddenly, poof, your network share goes down, and your file is gone, and all of that work is lost. Naturally, an email comes in from IT saying, "Sorry, folks, looks like
00:35
our file server is down. We'll have it up as soon as possible." Looks like you're working another Saturday. Lucky you. What if there was a better way to do this? What if there was a way we could put file shares out there that were always up, no
00:50
matter what? Hey there. Thanks for joining me on this walkthrough video of Active Cluster for File on FlashArray. I'm Don Poorman, Technical Evangelist here at Everpure, and I got to tell you, this feature that we've released has been the most requested feature since we had the ability to
01:13
deliver NFS and SMB file shares a few years ago on FlashArray. And now it's here. So what are we gonna cover in this Pure360 video? Well, first, I apologize, but we are gonna have some obligatory slides on getting to know Active Cluster for Files, how it works, what its configuration looks like.
01:31
We're also going to include some slides that are dedicated to Murphy's Law, which is what happens when things break in your Active Cluster for File configuration. And then we're gonna sit with Quinn Summers, who's put an incredible demo video together that talks about how you configure it, how you manage it, and ultimately what it looks like when you do have a failover event.
01:52
So with that being said, let's dive in and kick the tires on this feature. Okay, before we get into the demo, let's do a really high-level view of what to know about Active Cluster for File on FlashArray and some of the things that need to be in place before you actually are able to leverage it. So let's start with why Active Cluster for File in the first place.
02:16
Well, the value proposition is pretty simple. It's a synchronous zero data loss replication. The mediator itself can be hosted either internally in your data center or via Peer1. And there's approximately a ten-second failover from one site to the other, which is definitely industry-leading as far as time is concerned.
02:35
There's also the fact that Active Cluster functions across two arrays themselves, and there are geographic limits to it, as well as latency requirements and bandwidth. But it's an active-standby architecture, and the standby array has a mirror of the data, metadata, and the configs itself. And the user experience, it's built right into the GUI.
02:58
Everything that you know how to do with Active Cluster is also available with Active Cluster for File. Fusion is also an option to use here as far as setting things up across a fleet, and there's automatic array failover. Now, what about the protocols and clients?
03:14
Well, the supported protocols are what you would expect, NFS v3, v4, SMB, SMB continuous availability, and multi-target DFS with DFS direct. But the client operating systems must be within the FlashArray File Services support matrix for those protocols. You can find that on our support site.
03:35
All right. Now that we understand the value of why Active Cluster for File, let's talk about some of the prerequisites. First off, there are the obvious things, right? You need two FlashArray systems, whether they're Xs, XLs, Cs, or Es. You're gonna need Purity six dot twelve dot x or better, which is a feature release version
03:55
of Purity itself. Both of your arrays obviously have to support Active Cluster synchronous replication, either via IP or fiber channel, and they all have to be enabled with these prerequisites. Now, the mediator, you can either host it in Peer1, or if you don't do that, and you have a dark site or it's just not something you would do, you can host the mediator virtual machine
04:19
in your data center itself. The networking, well, from an IP perspective, four replication IPs are required per array, and the ports on the array have to be capable of seeing each other. So the primary's gotta see all the same four ports on the secondary one. If you're using fiber channel, you also need four dedicated fiber channel ports for that
04:41
replication with the same idea that they all have to see each other between the active and the passive node itself, and you have to have the replication service turned on. For latency and bandwidth, since this is synchronous, we are a little more sensitive on latency. You have to be less than eleven milliseconds as far as latency is concerned and have enough
05:03
bandwidth size for the amount of stuff that you will be replicating. That's obviously something you can monitor into through the dashboard in your FlashArray itself. And as far as the management ports are concerned, all the management ports on both arrays are all connected so they can reach wherever your mediator is, whether it's local
05:23
or if it's up in Peer1. The other possibility here, which we highly encourage, is that even though Fusion is not a hard prerequisite, we still encourage its use as far as being able to manage into fleets and multiple arrays and things along those lines. But the way this works is you still could just do this through the GUI on the individual
05:46
arrays themselves, as you'll see in the demo.With the prerequisites out of the way, let's take a look at the higher level of what Active Cluster for File looks like. Obviously, we need two arrays to be able to do this, so we've got a flash array that acts as the active array. We have another flash array that acts as the standby.
06:06
They're both connected, like we said in the prerequisites, via IP or fiber channel. And then there's a third component in this, and in this case, it's the cloud mediator that's hosted in Pier one. The cloud mediator itself acts as an overseer and ensures that should the active array suddenly not become available, things get cut over to the standby array.
06:28
But in the case of what we're looking at right here, this is what happens when it's working normally. Your SMB and NFS clients have read, write access to the file system and manage directories on the active array itself, and everything via synchronous replication is mirrored over onto the standby array itself.
06:46
If there is a failover, the mediator will detect it and cut over to the standby array and redirect all of the clients as well. If there's a failback event after that has happened, that's gonna be handled by your policy, whether it's automatic or manual itself. And again, in the case of what you're looking at right here, the mediator is actually hosted
07:07
in Pier one. That's why we're calling it the cloud mediator. Okay, so you've seen what it looks like when Pier one is hosting the cloud mediator, and this is what it really looks like when there's an on-site mediator as it relates to configuring Active Cluster for File as well. See, there really isn't much of a difference here.
07:27
The steps are all the same on the right there. The biggest difference is that your on-site mediator is actually configured locally to connect to your management interfaces and runs as a form of a virtual machine in your environment. All right, it's the moment of truth.
07:43
What happens when the active array fails in an Active Cluster for File scenario? In the case of what we're talking about right here, before I get into it, we are just going to refer to the mediator itself. We're not gonna discern between cloud mediator or on-site mediator. Anyway, in the event of a failure, the active node goes down.
08:01
The end clients can't see their shares on that active node. The mediators will then, within ten seconds, redirect all of the NFS and SMB traffic to the new array, which is the standby array itself. That one becomes the active array, and the mediator continues to monitor the two arrays to see if the active one comes back up.
08:24
And if it does, the failback is either automatically handled or manually based on the policy that you've set inside the GUI. If you're an IT professional, you know that you are occasionally going to get hit with situations that you never planned for. So let's take a closer look at some things that could happen to your Active Cluster for
08:44
Files configuration under the banner of Murphy's Law, that anything that could go wrong will go wrong. The first Murphy's Law scenario is actually pretty straightforward. What happens when the mediator goes offline? Well, if it were to go offline, everything still continues to operate as designed.
09:04
The active and standby nodes will still continue to work with each other in a synchronous replication fashion, and the end clients will still be able to reach all of the data shares that they are accessing on the active array as well. The second Murphy's Law scenario is something much bigger, and I think if it happens, you've got bigger problems to deal with.
09:27
But what happens if the mediator and the link between the two arrays goes offline? Well, the mediator goes offline and the active-standby can't communicate with that link down. What's gonna happen is neither side is gonna be allowed to continue IO to avoid the split-brain problem, because we don't want these arrays out of sync with regards to data
09:48
integrity between the two. Which means the hosts themselves, the end users, are going to lose access to those stretched volumes until the connectivity to the mediator or between the arrays is restored. That's kind of a worst-case scenario and really the second Murphy's Law example.
10:09
And there you have it, a really good high-level overview of Active Cluster for File, the prerequisites, what it looks like logically, and what to expect in various failure scenarios. Let's see it in action with this demo video that Quinn Summers put together. Okay. So with that being said, I have two simulators up and running right now, VFA one and VFA two.
10:31
They're relatively brand-new systems with almost nothing on them. So we are going to begin, by connecting these arrays. So I'm going to go to protection. I'm gonna go and create an array-based connection. So I'm gonna say connect that array.
10:45
here we're going to enter into the IP address of the secondary controller, which is this IP address. we're going to choose synchronous replication. We need a connection key, which is as easy as going over here, going to protection. This is the secondary, array that I'm on, by the way, and I get connection key.
11:08
So this is the shared secret between the arrays that'll allow this replication link to share the metadata and the user data synchronously across the both arrays. So now we have just created that brand-new sync replication array link. For the next step, what I wanna do is I want to go ahead and create a realm. a realm for Active Cluster for File is our container for our file systems that we want to,
11:33
stretch across both arrays. So in this instance, we're gonna go ahead and create a realm called realm one. That is good. and then I'm going to go ahead and stretch that realm right now. Stretching is the verb that we use to say, "I want to synchronously mirror everything with this in the container or this realm one to my
11:52
remote array." And anything's inside those container will not look like duplicates of each other. It would just look like an up-to-date version that's stretched across both sides. So we go in and stretch that. I hit refresh, and now we can see both things, should be in the online state.
12:09
Excellent.So we have stretched our realm. The next thing that we need to do is that we need to configure a, a server within that realm itself. so our servers are our protocol endpoints. they are how we access storage.
12:23
so I'm gonna go to Storage, I'm gonna go to Realms, I'm going to go to Realm One, the one that we just created. Over here, we have no servers created or configured, so we're gonna go kick off our server wizard by clicking on this plus button. this is a guided workflow.
12:38
we're gonna create a server name. We're just can keep it really simple, for test purposes. Hit the Next button. Here, we're creating the virtual interface that is going to be accessed by our application.
12:50
So I'm gonna give it a s- Purity storage name called syncfile. This is just the internal name to Purity. I'm not gonna select VLAN tagging, although we will support that. I'm gonna specify my IP address and my gateway. So this is the IP address and my gateway of the virtual interface that I want to float
13:05
between both FlashArrays that are synchronously mirroring the file system. Sub interfaces, these are the physical Ethernet ports that I'm going to choose. In the dropdown menu, it gives us pairs across both controllers, CT0 and CT1. That looks good to me. I'll go ahead and select that. The next step is, setting up DNS.
13:24
I'm gonna use our default DNS settings on this array. And then for directory services, for the purpose of the demo, I'm not going to use user mapping. We're gonna just trust the client's credentials or whatever they pass us, and hit the Next button.
13:36
Gives the preview of the actions to create this server, and then we hit Create. And so now this wizard will issue these API commands, configure, this for us, and then looks like we're done. Okay, so we have a server up and running now, with, our IP addresses. Next, we need to give it something to actually access.
13:57
and so let's go to our realm. We'll go into our file systems. We'll create the plus button to create a file system. Let's give it, FS1. Hit the Create button.
14:06
All right, we have a file system. now we need to create a export policy, that we can access that file system from. so let's go here. Go to Policies. I'll create a new export policy.
14:20
My realm, I'm gonna select the realm that we created, Realm One. I'm going to name this, name the policy Open. I'm going to disable user mapping for the purpose of the demo. Hit the Create, and now we have that, open realm, NFS policy. We're going to add a rule.
14:37
We're gonna make sure that all clients can access, access it. We're going to, allow root, ID to come in. we're not gonna squash it, and we're gonna use Auth Sys for right now. That's totally fine. okay. So now we have rules.
14:52
We have a server. Now we just need to associate the rules with the server. And so, what I'm going to go ahead and do is select our server, Realm One, select my directory, root one. For my export, I'm gonna say syncfile.
15:06
This is what I'm gonna mount for my client in just a moment. I'm not gonna enable this right now. I'm gonna hit Create, and then all of a sudden, we have active cluster with data being mirrored from one side to the next. There's a couple of more steps that I wanna do though.
15:20
So if we go to, Protection, and I go down to, my active cluster here, and I look at my array, right now I see sub interfaces. I only see two assigned, and that's not, something that, that I necessarily want. I want to add an additional two Ethernet connections to this, and so I'm going to go
15:42
and add those right now. I'm going to go to Active Cluster, gonna go into the realm. We see our interfaces here, and I'm going to hit Edit. I'm gonna go ahead and select two more, because we want file interfaces, physical Ethernet interfaces, associated with that virtual interface across both controllers and
16:01
both arrays. here it gives me a default, or a dropdown menu of interfaces that are available in pairs. I'm gonna go ahead and select these. and I'm gonna hit Save. And now this is updated.
16:15
this has updated, the realm with the additional physical Ethernet, information. So now we have four physical Ethernet ports. They are all supporting this singular IP address, and we should go to our client and be able to mount it, drive workload, and then see failover back and forth.
16:32
All right? Okay, so talking about that, let's, let's go ahead and start looking, get our performance screens up and running. file systems, we're gonna drop it down to five minutes over here. We're gonna do the same thing over here. File systems, drop it down to minutes.
16:52
And, now what I'm going to do is I'm going to go to our client. Here's our client. so this is a Linux client. I'm gonna run the mount command. I don't think we have anything mounted via NFS right now.
17:05
So I'm gonna go ahead and, mount, the NFS file system that we just created and it, and exported from that array. so here is that, export that we had. We're gonna go ahead and mount it on mount syncfile. And we are done for there.
17:24
If we, go into that directory, it should be, empty. All right, so we see a empty directory right now, and, what I'm going to use is I'm going to use a DD command, a Unix utility, to drive a bunch of workload. Okay? and, from here, I'll show you what the, what the command is.
17:46
All right. So we're going to, from this Unix client, that we've mounted the NFS file system, we're gonna take a bunch of information from dev/random, we're gonna start writing it out to a file within our mounted NFS file system. and we're gonna write a, a bunch of gigabytes to it, just so we get some traffic. We're gonna put it in the background too.
18:05
and now we should see file stuff kicking off, in just a moment from our...Uh, here we are from our systems. So there's delay on the performance analysis side. If we go to the real-time side, we see traffic on VFA one right now, happening. If we go to VFA two, we don't see that traffic because VFA one is, is serving all the reads
18:29
from it right now, right? so again, I'll go to the file system perspective. we're gonna drop down to five minutes, and we're going to show a workload. I mean, our workload is already running, but we're gonna show it what it looks like from here. Okay.
18:42
So that workload is still running in the background. I am going to now cause a failure condition. I'm gonna simulate a failures within our, simulators. and, right now we'll see cessation of the IO, a failure condition Oh, wait a minute.
19:01
There we go. Okay. Failover condition has happened now. we should see IO dropping. There it is. There's a cessation in IO, as we're having the failover command. Our DB operation though is still going.
19:13
And if we go onto the other side, if we look, for here, we should see the performance, picking up, right away in between the two. and if we look at the differences between the two, we see at eighteen forty-six, an oh two, dropping traffic from here. We go to the other V side, VFA that we failed over to, and we see eighteen forty-six oh four,
19:37
so super, super fast. That simulated network failure condition has, still processing rights, but this is processing it on VFA two. w- the, the leader, the where we are writing to to begin with was from the first flash array.
19:52
Then we disc- we disconnected that flash array simulating a failure. We saw the workload fail over automatically to the other side without remounting the file system, without DD stopping. There was a small cessation. There was a small pause, but that was about it.
20:07
And so, this is how simple it is to set up synchronous file solutions with Pure Storage's ActiveCluster for File, feature that we're super proud to talk about. thank you for giving me your time. I appreciate it. And there you have it, a really solid overview of ActiveCluster for File on FlashArray.
20:27
If you liked what you saw and you wanna dig deeper, hit up your Pure account team, visit our website, and visit our test drive site to see how it works firsthand. Thanks again for taking the time to watch this video, and we'll see you next time on Peer 360.