 All right. Good evening, everyone. So today, we are going to talk about fire drill in open stack environment. So before getting into fire drill, let's first try to understand what are the bad dreams of assist admins. So those are the things that assist admin goes through day in and day out. So let's think about some of them. What if an instance goes down? That's very important because your application is hosted here. What if a compute goes down? And of course, I mean, will my application experience a downtime, or how quickly will it recover? So there are other things which can go wrong, right? I mean, there can be a power failure. There can be a rack failure or a site failure itself. So those things, of course, require you to think deeply. So let's think about these things. Let's think about a simple compute failure scenario. So this is a hypothetical scenario that we have cooked up. So here we have a big server towards the left. And that server is 128 GB of RAM. There are three more servers. The bigger one is 64 GB, 32 GB, and 32 GB. There are two virtual machines hosted on the big one. One is 65 GB, and the second one is 34 GB. So what if the server goes down? So let's think of it as a real failure. Apparently, yeah, the server went down. But what we think is that the other servers will be able to host the virtual machine because the other server's total memory is same as the bigger server. But yes, that won't work, right? Because if we try to live migrate the virtual machine, now what will happen is it will fail with the insufficient resources. I mean, it's a simple example. And we'll talk about this in the fire drill context. This is just to explain what can go wrong. If you have not done your fire drill, you can end up in situations like this. So let's try to understand what is fire drill. So fire drill is a mock run of a failure scenario where an admin gets to predict whether my application will continue to run, or whether we can tolerate the failure or not. So there can be multiple things that can be done as part of the fire drill. Let's try to take this simple example and try to understand what this fire drill can be done in the similar environment. So in this environment, when the server goes down, so here we are trying to do a fire drill just to explain the concept of a fire drill. When the server goes down and you are trying to place the virtual machine, and if you are not going through the real failure, then we can figure out, OK, the application is going to fail because the VM cannot be hosted on a smaller server. And at that time, the recommendation could be that we need to enable the overprovisioning on the server. That's a simple recommendation. This is just the first pass. And once that is done, we can do a fire drill again on the same environment. And at this time, both the VMs will be moved successfully. And this is what will happen when the real failure happens. So this is just to explain the concept of a fire drill. To explain it more in detail, I'll pass on the mic to my friend Dhruv. Thank you, Narendra. Thank you. So this brings us to our original problem. Can fire drill make admin sleep peacefully and make him get rid of his bad dreams? So let's first take a look at what does fire drill provides to an admin? So with fire drill, an admin gets to know whether a VMHA is possible on his current setup and under his current specific circumstances under whatever his setup is running. He gets to know whether the data accessibility is maintained or not. He also gets to know how quickly can he recover his data. And he also gets to know whether the application continuity is maintained under a particular failure or not. So speaking of failures, let's just take a quick look at what all possible failures can admin experience. So we do have compute panics, so a compute node going down, making all your VMs inaccessible. We do have VM, we do normally see VM process failing. We do see media failures. We do see network failures. Then we see the entire rack failing because of some power outage or whatever. And then we see issues due to upgrades, the operating system upgrades and patching. So to get rid of this, an admin should perform some specific hardware drills. And those hardware drills should absolutely include checking off whether there is sufficient memory available in the remaining computes. And they are able to host the failed VMs or not. He should definitely see whether there are sufficient cores, whether there is sufficient storage capacity available, whether there is enough network bandwidth available and the network connectivity is proper or not. And then he should see whether the remaining computes are able to sustain or they have the residual IOPS capacity to give the storage SLA that are defined to the VMs. Apart from these resource checks, an admin should definitely see whether the quality of the resources available on the remaining computes is the same or not. For example, the compute that went down was having an SSD. But the remaining computes do not have that. So this clearly indicates that the VM SLA is not going to be maintained. Then he should definitely see whether there is equal network bandwidth available on the remaining computes or not. Then there is redundancy in power supply to the rack or to the nodes or not. And redundancy even at the network and the FC cable layer. So apart from these, he should definitely have some software drills as well. For example, whether OS upgrade is possible at this current position or not, then there are the relevant virtualization services, for example, liver D is running or not. Then the cloud services, that should be running on the particular node. They are running there or not. Then there must be some overcommit settings, like we saw in the illustration that Narendra provided, whether that is happening or not. So this brings us to the question and what do you guys think, whether is Firedrill enough? So the answer is definitely no. Firedrill is a helpful thing, but it is definitely not enough because it cannot provide an exact mock of multiple failure scenarios, which brings the entire setup in an inconsistent state. Then there are some real time changes happening all the time. For example, there is a peak in the traffic when the failure happened. And that kind of invalidated the Firedrill report that we had. Then there is this configuration change that happened. For example, after an admin ran the Firedrill report, he kind of removed one compute. So this Firedrill report is now invalidated, again, because of the configuration changes that happened after the Firedrill run. So we recommend running Firedrill frequently so that your setup has an appropriate and an accurate Firedrill report always. So from this, I'll pass on the mic to Vipul. And he'll explain how Veritas Hyperscale takes care of these bad dreams of an admin. Vipul. Thank you, Dhruv. So first of all, let us take an high-level overview of the Hyperscale architecture, as well as the features provided by Hyperscale. Hyperscale is an enterprise-grade solution which provides a two-tier storage architecture in which there's a primary architecture which consists of SSD as well as HDDs. It provides higher performance for the application workloads. While the secondary tier of the Hyperscale, it consists of a high-capacity HDD nodes, HDD data storage, which provides for storing of versioned workload data. And the backup application, it is integrated with the secondary tier of the Hyperscale. On the feature perspective, Hyperscale, it's an hyper-converged storage solutions in which it pulls all the HDDs, the DAS, on the compute nodes. And the performance scales as we scale the number of compute nodes. It provides for live migration of the workloads in the DAS environment. It provides for end-to-end storage quality of service, such that it insulates the critical applications of the workloads from the noisy neighbors. So how Hyperscale fits in, in case of a DR solution, is Hyperscale, it provides for alerts, as well as resiliency handling in various storage, as well as network resource failures. So whenever there's a storage error or a network resource outage, it will raise alerts, as well as handle those errors. It provides for application continuity in case of storage failures, compute node failures. The workload deployment is rack-resilient. It will failover to another rack in case of failures. It provides for real-time SLA violation alerts, as well. Coming to the end, so going to the history of Hyperscale, it was introduced in the Austin Summit, in which we introduced the Hyperscale for open stack solution. And then in the Barcelona, we introduced about the VM, residual IOPS-based VM provisioning. Now in this, we have introduced this intelligent resource monitoring for Hyperscale. Thank you.