Transcript
And I've got multiple tiers. I've got tier one through tier four. So tier one is NVMe, tier two is SAS SSD, tier four and five are your traditional spinning disk. In this case, it's 10K hard drives, SAS hard drives. So if we have a workload and we want to actually migrate the workload, it's very easy to do. I can show you very simply. If I go into, say, one of these individual servers here, I've got a SQL server running. All we have to do is open this up here, go to the drives. Let me go back here quickly, go to the drives. And I can actually change, say, for instance, I've got SQL data, logs, TempDB, backup. In this case, let's just say we wanted to change the TempDB. Very easy. Just hit edit here. You'll notice it says preferred tier. And all you have to do is change that now from tier one and just choose your tier. So let's just say we wanted to change it to tier four, submit. And then immediately, basically, it is now changed to tier four. In the UI, it's very simple to do. The better question is, what's the impact of doing that? I have a small app here. Let me just switch to it. Before I do that, let's go back and switch that disk again. Just one second here. I'll switch that back to, let me go to TempDB, tier one. So yeah, so we look here. So I've got an application which shows you kind of the performance. We've got a variety of different types of cases here. It's going to show you, essentially, the difference between a regular workload, SQL workload versus something that's write-intensive versus cold reads, which come off the disk from the physical disk itself and not off cache. But most workloads are typically your regular workload here. As you can see with the throughput we're getting, and this is on tier one here, you can see it here. Both the SQL data disk and the log disk are on tier one. And the storage latency is actually pretty good because it's actually coming from RAM. Anything that it's pulling and the throughput numbers bear that out here. And as it mentions, it's basically the working set is always being cached in RAM and the NVMe read cache. And so it's reading from memory, but the writes are absorbed by the NVMe journal so that it immediately comes back. Now you could change this. You could change the... And I've got an anatomy of one transaction, so let's just run that here. As you can see, the client put the request in, the server checks the pool, and it immediately saw that that page was in RAM. And so skip the disk entirely, and then it comes back in less than one millisecond, in this case, 146 microseconds. Extremely fast, and the latency is still good. The better question is, what if we move this? What's the performance if we move this to a different tier? So let's scroll down here, and let's just change this to say tier four. So in this case, I've got SQL data. I can hit move, and it'll move the SQL data disk, the volume to that particular tier. And so now it's moved, and I'll also move the SQL log. And we'll see here, and it's already moved as well. So they're both on the same tier. And as you can see, it doesn't really impact the latency. And the reason why, of course, is because, again, we're still using that read cache. We're actually... And the throughput is basically the same. Latency is the same. As you can see, it's pretty straightforward as far as the performance is concerned, and the latency over time is exactly the same, because it's actually getting pulled from the RAM cache itself. Even if you put your workloads on spinning disks, things are actually going to be answered from the RAM cache. And that's kind of what you want. You want the best of both worlds. You want to be able to take your workload and migrate them from one tier. Let's just say you're a tax company, and it's tax season, and you want everything on MDME. But then after the initial rush of people putting in their tax returns or tax filings or forms, then it's going to trail off. So you can move your workload to another tier and really not suffer any impact whatsoever, even though the number of requests coming in will go down. So I'm showing you the storage tier here. Just talking about tax companies, I actually did up a site for tax form, a tax company called LedgerLineTax. And so this is a demo site, which kind of shows you in real time what that impact would be. So you've already seen on the storage side, your standard SQL requests and really a non-impact when it comes to migrating your workload. In this particular scenario, this is a fictitious company here, and we can file our e-return if we put Jordan Miller, and we choose a state and e-file. It immediately comes back, and you can view your assessment here as an example. But the better question is, what does this look like behind the scenes here? If we actually go to the load simulator, we can actually fire off those type of requests here. So let's fire off 10,000 requests of people submitting their forms. And let's see right now, so we're on, data's on tier four. So let's move it back to tier one. And so it's going to migrate that workload, and it's doing that through the API itself, all in the background. The blocks are moving in the background, certainly. But we can actually fire off a request here. Let's hit here, and so it'll start running, and you can see we're getting about 727 filings per second, and the commit latency is just under, basically, less than a millisecond. I did 10,000 in that 13-second period of time. So the question is, we've got, we can actually change the disk here. Let's move this to 10k tier five. Let's have a look and see what the impact is, and let's, so it's migrating right now, and you'll see this in a second. Let's fire the same request off again, and let's see what the performance is. So let's hit peak load here. And so we're getting about 473, so a little bit less, but generally, pretty good performance. Latency's gone up slightly, but again, it's still running extremely well under that condition. And this would be in a season, necessarily, where you weren't getting 10,000 requests a second, right? So if you know your workload, the customer is in the right position to determine where their workload should be. In this particular case, LedgerLine Tax has decided that they're going to put their workload now on tier five because the tax season is over, and they're okay with performance being slightly lower, but still performant and answering the requests that come in. That's just a general demo here of that process. And again, as I discussed in the previous situation, modifying and telling Verge to set it from one tier to the other is as easy as going into a checkbox and actually choosing one tier over the other, and it automatically makes those changes on the back end. And so all you really need to think about is, where are the disks today, and where should they be tomorrow? If we're back to tax season, you just move to tier one, and we're good to go. And once you're out of tax season, you move into tier five, and you're able to take advantage of that somewhat a little bit slower. But again, because of the RAM cache, still getting good performance on spinning disks.
