 Hi, welcome everyone. This is the first demo for the today. My name is Murali Balcha. I'm the CEO of Trilio Data. We specialize in providing the backup and recovery solutions for OpenStack Clouds. Our offering is the first backup and recovery solution for OpenStack that is built on the same principles of the OpenStack built for the OpenStack. So in order for you to appreciate what we are doing, I'll play some scenario here. So we have Tom here. He's an IT director. I think we all can associate with him very well, right? So he's a passionate technical person. So he is passionate about the cloud. So in his IT, he designed a great OpenStack Cloud. It runs great. It scales very well, obviously. And as with any cloud, it is self-provisioning and multi-tenant. And it has multiple regions, right? And he sold the value prop of the cloud to his business units. And life is good, right? As long as it works, life is good. But then, especially when you are running this kind of initiative within your company, that basically spans across multiple business units. Each business unit may have different data management requirements, data retention requirements. Let's take a look at Sam now. So Sam is the DevOps engineer, right? You want to make sure that all the applications are running well and perform well. So if something goes wrong with the production, he should be able to troubleshoot any issues that are happening in the production without causing any outage, without basically bringing down any of the applications. So his need is, hey, can I take a backup of the production and somehow spin that production back up into a different availability zone or onto a different network without interfering with the production and do the troubleshooting do whatever he needed, right? That was his need. And Sam and Tom thinks, wow, that's an interesting scenario. Because when you look at the traditionally how people do, so I talked to my IT friend there. So he manages SAP. So he has SAP running on VMware. And so I asked him, how do you basically verify that your backup is up and running and it is in a restartable state? He says, yeah, that's a good question. So for compliance reasons, we definitely need to do that. So we plan that kind of validation of the backup for six months ahead. So they basically plan an outage for three days or four days. And then what they do is basically they set up an identical system. And then they basically take the backup and then restore all the data into that SAP system, the standby system. And they have to basically make sure that the SAP is in a recoverable state. So this is a real world scenario. But the business requirement, the compliance needs, is not going to go away with the cloud. But it's going to take a different shape. But those guys, they still need to meet those compliance requirements. But with the cloud deployments, with the different technologies that are available, we could be able to do it much more efficiently than planning six months ahead and planning a couple of days of downtime. And then look at Tony. Tony comes from e-commerce department. He has built this awesome application with all the latest technologies in the world, with all the scale, with all the replication that is needed. But he still need to take a backup. He need to basically retain the backups for six, two days. And his need is he has this complex backup that he's built, application that is built. And it spans multiple VMs. It has a lot of sender volumes that are mapped to. It has some security groups that are mapped to this application. So he need to go and basically take a backup on a regular basis of this application. So he always has a way to go back to a point in time in case something goes bad. Well, Tony has this, Tom has this dilemma. There are awesome applications out there, backup applications that supports VMware and the bare metal. They've been doing it for a long time. But they don't just fit into the OpenStack. OpenStack is a multi-tenant environment. So it's not like we have one central administrator who can basically go and backup everything in the cloud. So it should be kind of more like empowering the tenant, basically give the right tools so that your tenant, so the tenant can basically take care of their backups. So none of the traditional backups can really do that. So the next one is Mr. Smith. Mr. Smith from the corporate. So he understands the technology. He understands awesome power that the cloud brings into his IT. But then he still need to basically make sure that all the applications has certain RTO and the RTO to meet to, right? So there should be a proven process that he can basically check mark on that so his back is saved. So TrilliaWalt, this is from TrilliaData. So we offer a true backup and recovery solution for OpenStack. Ours is an add-on service to your OpenStack cloud, just like your compute node, just like your networking, just like Cinder, which is self-serviceable, scalable, all the awesome things that each of the service provides for the cloud. Ours is an add-on service to your OpenStack cloud. Once you install, it becomes part of your OpenStack cloud. And just like any other service, it is a multi-tenant self-serviceable. And one good thing about our solution is it is non-destructive. So whether you are basically deploying an 100-node OpenStack cloud or a thousand-node OpenStack cloud, it can be completely automated with the DevUptils. So we shape a playbooks for managing our deployment and upgrade. So you can integrate with your playbooks, like Ansible playbooks. And you can automate end-to-end deployment of our offering with your cloud. So what do we do? We are the first native solution for OpenStack cloud. I kept telling this, OK, we are multi-tenant. And the important thing is we are agentless. So we don't run any agents within your guest. So this service is provided at the infrastructure level. But we also work with the QEMU agents that are running in your VM if you want to take applications consistent backup. And more importantly, we are one-click backup and one-click recovery. So no matter what the size of your application, whether you are doing two or three VMs backup, what our complexity of your application is, your backup is one-click. We identify, we basically go through all the resources that are mapped to each of the VM. We take the right backup. And we support full-end incremental backups. So what I'll do is in this demo, it's around 10 minutes demo, I'm going to talk about how a tenant can create a backup. And then we also go through three scenarios, how they can restore a particular backup, whether a full backup, which basically takes a particular point in time and then restore or rewind your production back into a particular point in time. The next one is how they can use our restore operation to recreate our backup onto a different availability zone or onto a different network, onto a different region. And the third one is sometimes the backups tend to be pretty large, like depending on the application. Some of them may be 10 gig or 20 gig. So if you accidentally deleted a file and then you realize two days later that, well, I lost that file. Somehow I need to recover that file from your backup image. You don't have to restore the whole thing. So in that case, we support a file level restore, no matter what your size of your backup job is. So I'll also demo how the file level restore works. So when the product is installed, we add our own panels to your dashboards, one for the tenant dashboard, and that is for the tenant to manage your backups. And then we also add a panel to your admin dashboard. So admin dashboard is purely for administrative purposes. It provides overview of how our solution is performing in the open stack, how various backups are performed. So I'm going to demo all these aspects in this short video that I have. So this is the admin panel that I was talking about. So in the admin panel, the user has three VMs, Cassandra VM, MySQL VM, and then maybe a Tomcat, maybe some kind of web application that this tenant is running. So he wanted to set up a backup for this entire application. So we have a wizard there. And the wizard lets you basically identify what VMs that make up that application. This one is similar to when you create an instance, Instant has its own wizard, how to create it. It's similar to that. You basically set up the scheduling policy, how frequently you want to take a backup. And then you also specify how many snapshots that you want to retain. So ours is a forever incremental backup technology. So that means once you take a full backup, you never have to take a full backup again. In the back end, we synthesize your full backup from the incremental backups. So creating a backup job, creating the definition of backup job is pretty straightforward. And then once you have a backup job, it basically shows you the details and what VMs make up that backup job. You can leave it there so that the job scheduler regularly take the backups of your VMs on-demand basis. You can take a backup. We figure out whether it needs to be a full backup or an incremental backup. You don't have to basically specify what you need to take. And the other thing is, since you remember, we identified three VMs as part of the backup. So we also take a look at everything that is mapped to your VM. So for example, between two backups, if you added a new sender volume or you basically went and changed some network settings or security groups, in the next backup, we capture. So our snapshots are comprehensive snapshots. It includes your data and also metadata that is associated with our application. So when we restore, basically, we re-orchestrate the whole backup job back into the production. So here we are taking a couple of backups. So I like to run this one for a day. So it has a bunch of backup jobs created over the period of time. Now I want to go back and restore that particular point in time because something bad happened on the production. So this is a one-click restore. So you don't have to basically do any guesswork. So with a one-click, you can go and restore your entire backup job back to the production. So during that restore, we create all the VMs. If it even lost your glance image, we restore those glance images. We connect to the same networks. We assign the same IP addresses. We create the sender volumes. We map the sender volumes. So at the end of the restore, you have your application pretty much up and running. So what we don't do is we don't assign the floating IP addresses. But once you assign the floating IP addresses, your restore is done. So that is the full restore. The second part of it is the incremental restore. So sorry, not the incremental restore. So incremental to a sandbox. So you have your production. You want to let it run that production without interfering with that. But you want to restore to a different sandbox, maybe different availability zone, or different network. So this wizard will help you define what that sandbox is. Once you define what that sandbox is, and then we go and restore your backup job onto a different sandbox. So the use case here is again, if you want to do some testing, you want to validate that your backups are working all right. So you can leverage this feature to restore a point in time of backup to make sure that your backups are in a recoverable state. So during the selector restore, I chose a different volume type because I was backing up from the CIF. But while restoring, I chose LVM volume type. I'm just clicking on that volume tab. It's taking a little while. But you can see that all the volumes are restored, but now all the volumes are LVM volume types, not the CIF volume types. So this is the single file or single directory restored from your backup job. So as I mentioned, your backup job may be 100 gigs. So you accidentally deleted a file or a bunch of files. So this is a 3-VM backup again. Now you can go to a particular point in time. We support some operation called snapshot mount operation. And you click that one. So in that list of VMs that I mentioned, what we ship is, remember, this is all tenant driven. There is no administrator involved. This is a tenant panel, and tenant is managing their backups and restores. So we want to make sure that, obviously, the backup data, only you can access because that's your backup data. So in order to facilitate that, we also ship a small VM image that has some file manager, web-based file manager up and running. So you need to create a VM. And then during the snapshot mount operation, you need to identify that VM. So during the snapshot mount operation, it takes less than one minute, no matter what your size of your backup is. It basically goes and calculates what are your backup images. And then maps all those backup images to that VM you chose. And then it rescans any LVM volumes that you have, any file system that you have. And then it mounts all the file systems and then spins up the web application. And at the end of this mount operation, you have a URL. You can access your floating point IP of that VM, go to your web browser, and you get a list of all the files. So where you can basically download any directory or the file from that listing. So mount operation is complete. It took less than one minute. So that is the floating point URL of the VM where we mounted all the backup images. So you go to the web browser and type in that IP address. Now you have a list of all the files that were at that point in time. And you can drill down that, and then you can download any files. So this is visually appealing. But if you want to doing a bulk transfer of the files, you can do ESCP command to copy the data from that VM to wherever you want to restore to. So that we covered the tenant aspect of it. So tenant is fully empowered to take their backups. What about the admin? So admin has to make sure that the entire backup is up and running, the service is up and running. It's not causing any bottlenecks to your open stack. So we integrated into the administration panel. So in the admin panel, it gives you all the list of backups that your tenant has ever created, including a lot of performance metrics, including how many backups are scheduled, how many backups were there, and how much data that each tenant is backing up, and how much time is taking. And when they are scheduled, if they are staggered evenly or if they're staggered too closely. So it gives you all the information about our solution to the administrator. So one of the important aspect we surface is the storage panel. And in the storage panel, it gives you all the NFS shares that were configured to basically take the backup. So you can configure multiple NFS shares in order to scale the capacity of the NFS shares. We aggregate all the capacity that is added. And then we manage your capacity. So the administrator need not worry about it. Tenant need not worry about it. And it has different stats on how the storage is used by various tenants. So this can be also used to charge back your tenants if you have a charge back mechanism in place. So that's the end of the demo. Thank you.