 So yeah, we'll be talking about elastic OpenStack deployments. We have this massive data center, 15 megawatt data center which is shared among five universities. Like any organization or company, these universities also have multiple clusters which are operated using different deployment solutions. When people are using different deployment solution, usually they are married to their practices, they have this battle-tested systems, and introducing a new system in such an ecosystem is always difficult. I mean, the IT administrators don't want to try something new, and it's very difficult to convince the management to give you extra hardware to try out a new solution. So how do we get OpenStack into such an ecosystem? So ideally, what we envisioned was that we can start small, and as the OpenStack gets popular, more and more users starts using it, we should be also be able to scale OpenStack using the same hardware that was dedicated to different clusters. That way, we can have a scalable OpenStack cluster which can match the popularity as it grows with the comfort of people as they learn it. The problem with this is that IT administrators would only let go of their hardware if they have a guarantee that they're going to get it back when their users want it. So we wanted to develop a system which can do this to this quickly. And to tell you a secret is that we at MOC are having this small cluster, and ideally, we would like to take over the whole data center because OpenStack has a varied use cases and we'd like to make it popular across. But to do that, we will have to have a comfortable transition from an existing provisioning system to OpenStack. So how do we do that? We built a system and we believe that that system should be compatible with most of the provisioning systems. It should be secure enough that mutually non-trusting teams can play safe and well by sharing the hardware in such a cluster. And it should be fast enough that moving the hardware from one cluster to another, one provisioning system to another, makes sense. So to address the first two issues, we developed a system called hardware isolation layer. This layer is a fundamental layer which sits between the bare metal systems and the provisioning systems, and it lets you move the hardware between clusters very quickly. It is secure in the sense that the nodes are on their own private network when you try to build your own cluster. And authorization and authentication is managed by Hill. It is compatible with all the provisioning systems. That means Hill does not prescribe what provisioning system you use when you make your cluster. You can use any provisioning system you want. And you can use actually get native performance. Like it doesn't come in between. There is no performance cost. Hill itself is a very small, the core code of Hill is very small. It is 3,000 lines of code. And mostly it is extensible because we believe we have based it on our driver model. And we have drivers for various switches right now. Dell, Cisco, Brocade, we're working on other drivers. So we can support new hardware as we go on. And we can also support new services. Like Hill comes with out of the box support for keystone authentication. If you don't want to use keystone authentication, it also has a basic authentication system. And if you want to try it out or develop yourself, you can go with a new authentication system and use no authentication system if you have a completely trusted environment. So as I said, that Hill can move the nodes very quickly between the clusters because it's just a matter of moving a VLAN and making some API calls to Hill. But still, the most costly step is provisioning. Most of the traditional provisioning systems take tens of minutes to do that. So we asked ourselves, can we do better than this? And actually, Apoor, can we do better than this? Let's find out. So as we started playing with different provisioning systems on top of Hill, we find out that the kind of agility and elasticity we are looking into, we are not getting that. Like those systems are slow. So we thought that these kind of systems are not for us and we decided to develop our own provisioning system called BMI, Bare Metal Imaging System. So BMI is a rapid provisioning and image management system that lets you provision your bare metal clusters like on-demand bare metal clusters within less than like six, seven minutes. So basically, BMI is based on this less provisioning where node boots up from a pre-installed image that resides on a storage system, on a really fast storage system, and that contains your operating system and any intended applications and OpenStack in this case. So because we were using BMI, we were able to achieve up to five times improvement. So why we've got this five time improvement? Let's find out. So this is an example where we show that to provision an OpenStack compute node using a widely used provisioning system such as Foreman, it takes around 25 minutes. Let's dive in deep and see why it takes 25 minutes. So when you want to provision it, you power cycle your node. It does a power-on-self test followed by sending a PIX request. Then your kernel is downloaded and your operating system is installed to the local desk. Then your node does another power cycle and another power-on-self test followed by PIX request. Then your operating system boots up. Then you install any OpenStack-related packages followed by any configuration changes. This entire time takes 25 minutes. But in our scenario, what we want, we want to move nodes between different clusters really quickly. We want to lend our nodes when they are not used to someone else and get them back. But doing this is not easy because when you give a node to someone else, he may also provision to the local disk and all your data is lost. So when you get back your node, you'll have to do it from scratch and reprovision your system and it'll again take around same time. So what if we were using BMI? Can we achieve speed? Can we reduce this provisioning time? So let's see. So a node power cycles followed by power-on-self test and PIXy. Then we chain boot into a pre-installed operating system that resides in an image on the network storage. Then we do all installation of related packages and configuration changes. This takes around 11 minutes. So we basically reduce it to almost half. Now, again, if we are using BMI and we are giving the node to someone else and even if he writes to the local disk, none of our changes have been deleted because all our changes reside in an image that is on the storage server. So now when we get back our node, our reprovisioning time is even less because we don't have to install any open stack related packages. They are already present. So using BMI, we were able to achieve this five times improvement. So an interesting thing to note here is that out of that five and a half minutes of time, most of it is due to post-time, the power-on-self test. So if somehow we are able to reduce this post-time, the provisioning time of a single bare metal node will become like around two minutes and the average time to spawn up a virtual machine in AWS is also around two minutes. So we are working on that. We have done some proof of concept and we are looking into different issues. I think we are really close to achieving that. Now that we have seen how BMI reduces the speed, let's see how it works. So BMI is based on HIL and SIF. So a user comes in, he reserves some nodes using BMI. He comes, sorry, he reserves some nodes using HIL. He comes to BMI and asks to provision the nodes. BMI talks to a data store, in our case it was SIF and we had some pre-installed images. It clones one of those images. It exposes a cloned image as an ischusy target, makes any pixie booting configurations and attaches the node to the provisioning network and that's how the node boots up. So now that you see that BMI is based on network booting systems, so a question we often get from different people that because you have this network mounted systems you must be getting constant network overhead and your application will be suffering a lot. So we ask our questions and we perform some experiments and we found out that actually the performance degradation is almost negligible. So this is an example of open stack operations but we also tested our system with database servers, with big data applications, with high performance computing applications and we saw similar results. And why we have been able to see these kind of results because today in data centers, in commodity data centers, the network infrastructure has improved a lot. Like we use 10 gigabit network interface cards a lot and the backend storage is really fast. So concluding my talk, I just want to touch base like what is the current status. So Hill is deployed in our production environment at Massachusetts Open Cloud for the last two years. BMI is being used heavily by our different research teams. We are able to show that we can spawn on-demand bare metal clusters really quickly. And as a part of our ongoing research, what we are trying to achieve is can we somehow improve the disk access cost over the network and make it better than the local disk access in BMI? Can we have different others? We are exploring into those kind of solutions. Another issue of sharing physical resources is that there can be hardware security issues like people, if you are not in a trusted environment, what can happen is someone can install a rootkit and you are just like, you compromise your hardware. So basically we are multiplexing the hardware. It's time multiplexing between users. So we want to save the new user from any malicious older user or in case the older user has left some data, we don't want the next user to take advantage of that. So we are actually exploring a secure framework in which this nodes can be shared between different tenants. Yep, and also we are looking into different reservation policies and scheduling policies like especially in terms of cloud when the utilization is low, can we move some of the physical nodes and give it to some other cluster and see what happens? Basically increasing the overall utilization of a data center while managing different workloads. Exactly, so yeah, that's all from it and if you want any... Yeah, we are an open source project so we will like contributions. You can contribute new drivers, suggestions, feedbacks, look at our code if something is broken, fix bugs. We are welcome to do that. Thank you, thank you.