 Ready? Hello. I'm Giri Basava from Trilio Data. This brief talk is about protecting your workloads running on OpenStack Cloud. How many of you lost a credit card? It's easy to lose, but you don't have to worry about it because you don't have to worry about you don't have any liability. You call your financial services company and they will take care of it for you. But what if the same financial services company is running their workloads on OpenStack? They cannot offer to lose any of your data. It goes for any industry, health care, government. If you are running your workloads on OpenStack Cloud, you cannot offer to lose your data. Either to corruption or data loss, you cannot offer to. That's what we want to solve. Our team has a diverse background, most importantly in the disaster recovery and backup areas. And we are the first OpenStack backup and disaster recovery proposal, Raksha, that was proposed in 2013 for OpenStack. And it is being used by the Fortune 500 companies right now. What is Trilio Data's solution? It's backup and disaster recovery as a service. It is built for OpenStack, plugs natively into OpenStack, and it integrates with your Keystone users and provides tenant-driven data protection for your OpenStack workloads. It's downloadable, flexible, and it scales horizontally with your cloud, five-node, 100-node, 1,000-node compute clusters. So what do we do with the TrilioWall solution? It's not only your data, it's everything. It's an environmental snapshot and backup. We capture the application, the operating system, the compute, networking configuration, storage, most importantly, storage, and the security groups, et cetera, capture all that information. Let's quickly dive into the demo, see what it is. Let's start with an example. Let's think about a workload, a simple workload running in your OpenStack cloud, which is you have a WordPress in a VM and MySQL as a database, and it's nothing but a blog site. Simple, two VM workload running on top of your OpenStack cloud, your tenant is managing that workload. What happens if that workload fails? It could fail for any number of reasons. Manual error, somebody deleted those virtual machines, a tenant accidentally deleted them, data got corrupted, your workload is lost. What happens? The tenant or any user cannot access that blog site. So what are we going to do? Either they can call your operation center and say, hey, I need to recover my OpenStack workloads, then it's not a true cloud model. It needs to be self-service. So we enable that with a tenant-driven workload recovery. Tenant logs into Horizon dashboard. They have a backup stab that is available. They can click on the backup stab, go, and they pre-configured some data protection policies. In this example, they have a workload called a web server with MySQL. That's a simple workload. And they already have taken few snapshots, full as well as incremental snapshots. They're going to pick a snapshot, for example, snapshot 2. Let's drill down and see what it contains. This snapshot is an incremental snapshot. It contains two virtual machines, which is MySQL, of course, contains transactional data, and the web server, which contains your WordPress plugins, configuration, et cetera. When they configured this workload and captured that snapshot, when the backup was taken, the data that captured includes the security groups, the flavors, the networks, those VMs that were how they were connected, the volumes as well, both glance and cinder volumes. All that information is captured, stored on a different set of spindles than your production. Well, let's restore our blog site. So we offer two kinds of restores, one click, a simple one click restore, where a tenant goes in, my VMs are gone, I just want to restore the entire workload back into my open stack cloud again. They can do that. Or they can choose more fine-grained granular controls, selective restore. With this selective restore, a tenant will be able to restore it into the same availability zone with an open stack, or a different availability zone. And then they have more options. They can choose different network mappings. They can choose different volume types between SAF, NFS. What if you have two tiers of cinder volumes? You have something that's running on spinning disk, and you want to move your workload into a cinder tier with flash disk for performance reason. For whatever reason it is, you could migrate your workloads at the time of restore easily between different cinder types. And you also have an option of choosing which instances or virtual machine that you want to recover. You can include a VM in a restore, or you can exclude that. Not only that, you will be able to change the flavor at the time of the restore. If it was a medium, you can choose an extra large if your workload requires it. We did the selective restore. Once the restore completes, you will be able to see those VMs, two VMs, that we lost. They were restored back. So these two VMs were restored. What about you don't want to restore the entire VM? So again, as a tenant, you just want to replace a corrupted configuration file. We do offer that with a tenant-driven file recovery. With a tenant-driven file recovery, tenant again picks the snapshot and chooses to mount that snapshot within their tenant space. Once they choose the snapshot to mount, they will have a couple of URLs that they can go and browse the file system of that workload. Use that URL, paste it into the web browser, and you will be able to browse the file system and pick a configuration file that was corrupted and restore it and continue your workload. You can also use SCP to copy the data if you need to be. Here, we are mounted the snapshot. We are browsing the file system for the right file. We copy that file, restore your workload back to where it needs to be. Once you are done, you can mount the snapshot. This is where we're going to configure the workload. We have seen a workload that was already configured for the data protection. Let's go ahead and see how a tenant can configure a policy-driven data protection. Here, click Create Workload. Pick the type of the workload. We do offer a few choices. Either the VMs or instances, you snapshot them parallel, in parallel, or in serial one after another. Or we have specialized workloads such as Cassandra, MongoDB. And we also support polyglot environments. That means multiple databases, a MongoDB, as well as Postgres in a workload together. We do take application-aware consistent snapshot that workload running in OpenStack. And the data and metadata of that workload will be stored in your backup media. It actually, the two types of backup media we do support, both NFS and Swift Object Storage. Here, we are also defining the protection policies. Not only the instances and the type of the workload, you can also specify when to start your snapshot, when to end your snapshot, the frequency, and the retention policies. When do you want to keep 30 days' worth of snapshot? Or we can even specify full backup interval. Always do full backup, never forever incremental backups. Or after x number of incremental snapshots, you can always choose to take a full snapshot. And it's all configured by Tenant. If you are an operator, you offer it as a data protection as a service. And the Tenant can drive it. So here, for that simple workload, you can run it through a scheduler. Or you can manually initiate a snapshot. You can choose either full or incremental snapshot. So within OpenStack, it's an API-driven approach. Everything needs to be APIs. And also, it needs to be CLS as well. Similar to Nova CLI, Cinder CLI, we do have our CLI where you can create your workloads, your snapshots, you can mount them, you can delete them, you can change and modify your policies, when to snapshot them, and retention policies, et cetera. It's very native. It works with your Keystone tokens, just like your Nova CLI or Cinder CLI. And it's an API-first approach. We design the API, and then we design the UI on top of it. In fact, API and CLI has more functionality than what you have seen in the Horizon UI. And you can integrate this using these APIs into your own dashboard, into your own workflows if it needs to be. Thank you.