 Hello. Hi, guys. So welcome. My name is Andrew Shara. I'm the VP of the development at VM Turbo, and I want to talk about some of the experiences we had as we work with a number of our large customers across various industries that are rolling out OpenStack-based virtual infrastructure, and how we've been helping them, what challenges they faced, and how they showed the performance of the applications running in their environment. So I don't know how much you guys have heard about VM Turbo. We've been around for, we started the company in 2009. We've got about 1,300 enterprise customers, a large mid-size enterprise customers running a variety of infrastructure data centers based on usually a mix of different technologies from KVM, OpenStack to VMware as well as public Cloud options between Amazon, Azure, and we've been helping them to assure the performance of the applications by providing them with a control system, a control system that is able to understand the demand that comes from the applications and how to match it to the supply of the infrastructure that is running. It's very interesting how we could actually assure the performance of the applications in a large OpenStack environment, very much like in other environments as well. So just to get a bit of a feel, so how many of you guys are running OpenStack in production? Very cool. In terms of size of the infrastructure, anybody with less than say 200 servers? I'm sorry, more than 200 servers, maybe. Okay, cool. More than 100 servers. Very cool. How many of you are running a relatively important production and mission critical applications? Okay, cool. So what we see is actually interesting to attend a series of OpenStack summits as well as to talk to a number of OpenStack customers over the last couple of years and see the adoption growing in enterprises from financial to technology to telco and we actually have pretty good spread of all of those customers, and how it's increasingly more important to be able to make sure that the applications that you're deploying are not only agile there can be deployed quickly, but they actually provide level of service that the users are expecting. So as you are talking to customers, we've seen a number of interesting challenges in terms of how do you manage this workload, how do you assure the performance of the applications and the number of shortcomings that while the technology that OpenStack Out-of-the-Box provides is really good in terms of making it easy to spin up additional workload. There are limitations in both how do you decide initially where to place an application, how do you continuously assure the application performance, both in terms of deciding where to run the workload as well as how to choose the right flavors for the right workload and really what we want to help people with is to be able to run OpenStack with KVM as an enterprise private Cloud. It basically offer it as a viable production, large-scale, high-density virtual infrastructure, much like other technologies that people have been running in the data center in the past. And basically to contribute to OpenStack and as well as to add on our commercial offering to continuously provide this application assurance, to provide intelligent workload management and control in the environment. Now just a bit about what VM Turbo does to give you a bit of a perspective. So basically VM Turbo is a control system that plugs into all the layers of the data center stack from applications down to the infrastructure. And it's aware of the different workload that you're running in the environment constantly and in real-time. And it basically matches it to the underlying infrastructure, allocating the sources as well as scaling the necessary resources to constantly meet the demand in real-time across a combination of dimensions, most obviously compute storage and memory as well as cost, business policies, compliance. And there's a couple of use cases that I wanted to point out in a way that we can help OpenStack to provide this production service building on the strengths that OpenStack already has, but providing this intelligent workload management capability on top of it. And by the way, at any point you've got questions, feel free to just stop me and ask. I think there are a couple of microphones out there. So one thing that's almost obviously a question as you offer, especially as you offer self-service capabilities, you need to decide where to deploy these VMs, do you have enough capacity, and what's the best place for that workload to run initially, as well as going forward. And obviously, you can't rely on humans to do this because you want this to be agile, you want this to be self-service and fully automated. And what we see from customers is they roll out large-scale infrastructure. They actually want to differentiate their services. They want to offer different tiers of services and guarantee the performance of those workloads respectively across a shared environment. You could do this by segmenting your environment, but you end up wasting a bunch of money because some of your infrastructure is going to be over-utilized, some are not utilized, and you may not still assure the performance of the applications. And there's a number of other interesting use cases. As you run production environments, you have to worry about software licensing. How do you not only make sure that you're initially deploying the workload in the right place, but it continues to comply with your software license cost? And at the same time, of course, perform. We have seen a number of customers managing affinity and anti-affinity. And again, it's something that you have to continuously control, not just in terms of when you choose to deploy the first instance of application, but as you continue to manage, especially a large high-density open-stack environment. And the number of interesting technologies, there's a series of sessions on the evolution of live migration and even block migration in terms of the various vendors, storage vendors that are providing you better and better support. It gives you a good ability to choose any hardware, any compute, any storage that you want. At the same time, it enables you to decide where to run your applications, sorry. And to find the best place for your workloads, such as making use of local storage and still provide the mobility to be able to decide and actually control where your applications run within your data center. And this also helps us to provide better maintenance of the infrastructure. There are cases where you do have to do some maintenance. What you want to make sure that even while you are doing maintenance, your workload continues to run in places where it's able to get the resources that it needs. So you're just not just evacuating the host and blindly putting them someplace else, but you actually find the best place for your workload to run while you're doing maintenance on these hosts. So to be able to do this, VM Turbo contributes and takes advantage of both the instrumentation, as well as the control points that are available in open stack. So we have contributed a number of places to Nova, Silometer and to the API to be able to get the necessary metrics to understand what the real-time workload demand is. For example, how much disk, how much memory, how much CPU resources are constantly in real-time actually required for each one of your applications, as well as how your host and storage environment is being utilized. And based on this, make decisions both in terms of the initial scheduling decisions to decide where to place the workload in terms of computer and storage, as well as to, for example, life migrate the workload if it's a stateless workload, a stateful workload to find the best place where it should run. And we are basically relying for core projects primarily between Nova, Sinder, of course, Neutron and Silometer for the instrumentation and for these control points. Any comments or questions so far because I'm probably rattling through too many slides or not. And this is just a screenshot from our user interface where we have two ways in real-time controlling what applications are running where, what virtual machine instances are running where in the environment, how much resources they need to be able to perform and what's the best place for them to provide those resources. Both in terms of what applications are running on your VM instances, what is the most appropriate flavor for those instances to match the application demand with the understanding of the underlying infrastructure capabilities so you don't want to choose a huge flavor and run out of resources. But at the same time, find the best place for each of these instances to run, I'm sorry, within the environment both in terms of compute and storage. So what VM Turbo ends up driving is a series of actions that are in a closed-loop control being fed back into the open-stack environment in automated closed-loop control and not only showing you where your workload should run, how it should be configured, but it actually does it for you so it basically constantly controls the environment and makes sure that your application demand is met by the appropriate supply of your infrastructure. Some extent they are. So if you have shares in their services then you've got completely the one where to move your application. If it's running a local storage we are actually going to do block migration to move it to another host together with its storage. So we are aware of the dependencies between your compute and storage connectivity and able to find the best place for your workload and orchestrate and drive the actions, drive the API calls to make sure that you of course don't break your application while you're finding the best place for it to run. And by the way, none of these things are really completely independent so you want to make sure that you understand the full stack and this is really one of the most important points that we are making while OpenStack is primarily focused on providing IAS to your end users. What VM2 really provides is controlling the full stack, understanding your application utilization, your application scale out, match that to what virtual instances you're running, how those should be configured, where those virtual instances should be running across your compute and storage and we're actually driving the scale out of your compute and your storage as well. So we have the ability to bring in additional nodes, especially if you've got a software-driven data center, not just the IAS that you're providing or possibly scale your infrastructure back to provide a gradient data center if you don't need all of that computer storage resources. And I mentioned that there are a number of places where we actually contributed code back. So our philosophy in general that all of the instrumentation that is there in VM2, that is there in OpenStack should be an open source. So if we find that there are additional metrics that can enable us to drive better decisions and control the environment better, they may be useful for someone else as well. So being contributing those codes, they have been actually accepted into downstream distribution pretty much by Kilo, I think. So they've been out there for a while and of course we make use of them. We also have been contributing to the OpenStack Java API and I think additional capability as we end up both getting information as well as controlling actions back through the API into OpenStack and at the end of the day, you get better visibility into your environment and additional components that we are contributing continues to be available on our GitHub repository. And feel free to comment on them or improve them or fork them or make them better. I actually have one more slide. If anybody interested in more details on specific blueprints and reviews and if you want to drill down, of course you could get this through Stacklytics as well. So I think the slides are going to be available later. And then I thought that maybe we should do a quick demo as well, but before I jump over any other comments or questions, all right. So I actually have two tabs. One is a horizon dashboard. It's just the thing that happens to be Kilo, but in any case, any OpenStack environment, obviously, we are contributing and able to control anything since Icehouse. And another tab that shows our user interface. Our platform that provides this control capability is a commercial and closed source. You can spin it up in Amazon or Azure. You can run it in your private data center. All the components that are part of OpenStack are open source. In fact, they are part of the downstream distribution. So practically you could deploy our software either on your public or your private cloud. And as long as you have access to the OpenStack API without any modification, without any agents, you're able to provide this real-time workload management, real-time control capability on top of your OpenStack. And as I was pointing out earlier, sorry, the goal of our software is to provide this control capabilities across all the stack, all the stacks in your data center, all the way from the user-facing, load-balanced, virtual applications to scale the application instances that you have. And then what becomes a bit more relevant for OpenStack is how do you find where to start these virtual machines, what configuration, what flavors these virtual machines should have, what compute and storage providers they should run on and also manage the tenants or virtual data centers in your private cloud. VM Turbo, otherwise, also manages the same across public cloud zones and regions. And if it's a private cloud, it also manages the underlying compute and network and storage fabric across a variety of different technologies that you might have in your environment. But really the end result is based on all of the information that we get from the environment is to drive actions, to decide where a particular workload should run to be able to navigate across the environment and see, of course, the relationship between all of these entities and in the context of that relationship make the right decisions. So to jump over to OpenStack for a second, so this is of course a single instance of our software controls, multiple and multiple hybrid environments. I'm actually managing to OpenStack and one VMware environment from this instance. So if I actually drill in here, I have, this happens to be a VMware data center, it happens to be a Juno environment, sorry, not Juno. Anyway, one kilo of one Juno, I think. Two different OpenStack environments all controlled by a same instance of VM Turbo being aware of whatever is running in this environment and what actions we should drive to make sure that they are available. So to the previous use cases that I mentioned, if you want to make sure that you are not only making the right decisions on where to start the workload, but where do you want to continuously assure the performance of those applications around those workload in the environment, then any control system, in this case, VM Turbo has to be aware of a number of other constraints that are otherwise available in OpenStack, it's just that this control function is missing for them. So for example, if I want to limit where do I run Windows workload to these three hosts and where do I run Linux workload into these two hosts then notice that some of them are overlapping because some hosts are licensed for both. VM Turbo is aware of these Linux and Windows tags. So these are my Linux hosts, these are my Windows hosts. And as we decide to start the additional workload, it is not only controlling where this workload should start, but continuously finds the best place for your instances to run, so it only migrates them within those tags, which is pretty much the same thing that is available through most of the other scheduled drivers except they are only making decisions for the initial deploy and there is no easy way to continuously assure that whoever logs into an environment doesn't break it and move VM to a different place or ends up deploying it in the wrong place by some other accident. So otherwise, in terms of the end user experience, it's pretty much the same as what you would have for any other user, I'm sorry. So let's say I want to deploy 10 new VMs, I'm gonna put them on a public network and Obestac is going to schedule this workload the same way as it would everything else, but if you're looking at the scheduled driver, what it's going to do is it's actually going to, from the scheduler, continuously communicate with the VM Turbo instance, find the best place for each instance to run in the context of where, what constraints you have, what flavors you have and what's the actual current real-time utilization of your infrastructure, decides where to spawn these VMs and of course, feed that back into Nova to actually spawn those VMs in the right place and at the same time, discover those VMs and then start to monitor the real-time resource demand and match them to the best place where they should run based on their ongoing resource demand as well as based on the ongoing constraints that you see from the environment in terms of how your hosts are available and of course, all the other business or licensing constraints that you have defined. So what we see here is basically the scheduler just chugging through each of the instances that I'm starting and feeding that back into OpenStack and you see the instance is starting on the various hosts that, sorry, VM Turbo decides to start them on. So of course, you end up seeing the instances running as you would in any other OpenStack environment and if I go back to VM Turbo, we'll end up seeing a growing number of instances showing up. As like these guys, we start to collect metrics through Cilometer about their actual resource utilization and then continue to match them to the best available supply across the hosts that are available in the environment, whichever is providing the best combination of resources that they need in the context of everything that they are using CPU, memory, storage, network, IO resources and then of course, from there on as well as with any new workload, VM Turbo will continue to do this forever as long as you're running your data center. And that's pretty much it. Any questions or comments? Yeah, okay, so I think the question was how do you control the scheduler beyond what's available? So on one hand, there are a number of options that are available in OpenStack natively such as affinity and affinity rules, tags on the flavors and the host aggregates, all of those are picked up by VM Turbo, so whatever you configure in OpenStack are available out of the box in VM Turbo. In fact, they are being respected out of the box in VM Turbo. If you want, you can define additional workload placement policies that ends up becoming part of our abstraction. So you can choose, for example, that I want a certain group of VMs to run, for example, in a certain group of compute or storage providers. You could limit the number of instances that you want to run together. You could choose to make sure that you never place certain workload in certain resources. You actually can layer on top of what you get already out of the box with OpenStack additional constraints that might allow you to define additional business policies that you may not have captured in OpenStack. Obviously, all of these capabilities in VM Turbo will work across multiple OpenStack implementations. In fact, it will work across multiple virtual infrastructures that you run, not only across multiple private data centers, but across the combination of your hybrid cloud, your public cloud, and your private cloud usage so you could define business policies or business constraints that go across your whole hybrid data center on top of what OpenStack already exposes. There was another question. Yeah, question. Nodir from Zero Stack. Let me start from the abstract you provided and talk you gave. What is the ultra-high density workload here? So in general, what we see is that, if I play back to my slides for a second, is that most of our customers started out before they talk to VM Turbo solving these problems by segmenting their infrastructure, creating a separate host aggregate for Windows workload, creating a separate host aggregate for tier one, a separate host aggregate for tier two, and most of them end up wasting a large part of their infrastructure. So really, what we are offering to them is the ability to provide this real-time control that allows them to share the same infrastructure, respect the constraints, but actually achieve a much higher utilization of their infrastructure and still both comply with your business constraints as well as meet your real-time resource demand. I see. Okay, so it's less about workload, but it's about being able to like, don't let idle hosts stay there. Well, yeah. Don't let them do not aggregate, but run together. Yeah, so I mean, in general, in terms of, we don't really have a preference on how much you want to utilize the infrastructure. I think in general, we heard from most of our customers, they want to be greener. They also want to minimize their capital costs. They want to provide a viable alternative in their private data center to public options, so they find the right balance when they have to spend their money. Some of our customers trading financial institutions may run at a lower level of utilization, but they still want to utilize their hardware as well as they could and some of the service provider run at a much higher level of utilization. So it's really up to them what high-density means in their environment, but by allowing them to run on a much larger liquidity pool and a much larger shared infrastructure, they're able to better utilize the infrastructure that they have, and of course assure the performance of their apps. Sure, I have two more questions. If anyone has a question, go there and I'll stop. Otherwise, I'll keep going. So the second one is QAS. Yes. You said the market identification algorithm lets you provide QAS on NOVA and center. Can you elaborate more on it? Sure. So there's a couple of things. One is that by continuously being aware of what resources any particular instance needs and find the best place to run them, we're going to make sure that every application performs as well as it could. Now, if you've got a lot of resources, that's probably fine. What we see a number of our customers is that they actually want to run on less infrastructure, which means that occasionally they've got various dynamic workloads that are spiking at different times. How do you combine workload that's supposed to provide a higher level of service with other workloads providing a lower level of service? So really, we look at this as two ways. One is that there are building capabilities in OpenStack that are, for example, allow you to assign CPU shares to various flavors. We actually take advantage of that and we are finding a way to combine different workloads with different CPU shares so that you end up mixing the right combination of workload. So let's say that you've got a goal tier of service with X number of CPU shares and you've got bronze with half as much. How do you combine them together? So even if they spike, you can assure that the gold workload gets its resources where the bronze workload may not get its CPU shares. So what we do is basically pick up CPU share specs from the flavor. We look at how many instances have already been provisioned across your host and together with your real-time resource consumption, we find the best way to mix them together. So it actually allows you to differentiate at the same time, still use a shared infrastructure. I see. So your example was CPU? Yeah. But you do on storage and network? Yeah. So basically what we've done, and I guess I didn't really talk a lot about VM 2.0, but I guess I should. So in general, this is a pretty complex problem. There's a lot of dimensions. In fact, if you look at the whole stack, there is a whole bunch of things that one needs to control to be able to assure the performance of the apps all the way from AppStand to physical data center. And what we've done is actually created a abstract model, which is a marketplace of buyers and sellers and we implemented an economic engine that runs on top of this marketplace and makes these decisions. And what we actually done is that we represented every resource as a commodity that is being traded between these buyers and sellers in a supply chain and we make decisions based on what's the best place to buy the resources, the combination of resources that you need. Now, solving this problem on top of an abstraction allows us to actually plug in any resource, CPU, storage, network, actually, Java heap size, web server transaction rate or response time all the way down to physical power and cooling consumption and use the same economic engine to solve any one of these problems. So we may not have plugged in any possible dimension, but it's a fairly easy thing for us to do that given the right control points and the right monitoring end points. That's cool. Last question, VM migration. You said you monitor how much CPU RAM they're consuming and if you think they are given gold instead of bronze, so do you dynamically shrink and shrunk and move or do you tell the user and user decides or how that automation works? So our goal is to provide a closed loop automation and actually execute all of the actions. The whole point is that if you want to run a, not only a software-defined data center but a software-controlled data center, you actually need software to execute the decisions without having to ask a user on what to do. So we actually execute all of these actions. We change the flavor on a VM instance. We live migrate the VM to a different node in a real-time session. Sure, thanks. Thank you, sure. Okay, that was too easy. So I actually run the advanced solutions group as part of our dev team and what my team does is basically has been working on the next feature. So what we've been doing for the past, we've done most of our open-stack work about two plus years ago. So what we've been spending the last two years is we released our Docker control capabilities about more than a year ago and then over the past year, we've been actually applying the same technology to manage workload running in a Kubernetes cluster or in an OpenShift slash Kubernetes cluster on top of OpenStack or on top of a HyperCloud, Amazon or Azure. So we actually solved the same problem. In fact, it's even cooler, I think. In the case of Kubernetes, we contributed an open-source service that plugs into your Kubernetes cluster. It runs in a pod and it's constantly feeding information about what pods are being started, how the pods are utilizing resources and where they should run into our platform that again could be a private or SS-based instance. And in real time, we feedback that information into the Kubernetes controller and we're able to either scale up, scale down the number of replicas as well as decide where those pods should run and also when you need to spin up an additional node in your Kubernetes cluster and we are actually integrating with a number of orchestration tools from Red Hat, Canonical and others on how to actually provision the additional cluster resources if you need to, with the understanding of the underlying, say, OpenStack environment that you might be running from. Does that make sense? Anybody else? Yes? Right, so it's a very good question and it's, I think, probably the most interesting part of our technology, we're basically representing any of these constraints as a commodity and we are, in real time, calculating the price for every instance of every commodity. And if you want to represent the Boolean constraints, you could do a price of $1 versus a price of an infinite number of dollars, but in between those two, you can actually create your own pricing function and define how any one of these constraints should be priced. Now, the advantage and really probably the most important aspect of our technology is creating this common abstraction as a price because that allows you to trade off conflicting constraints with each other. So for example, we are taking advantage of flow instrumentation from OpenV switch, feeding it into our system and dynamically understanding affinity between different applications, different VM instances that are running in your environment and what our software does, it actually drives those workloads to run closer to each other by understanding both the overlay as well as the underlay network topology, the overlay traffic and the underlay network topology. But that becomes a conflict because if you move them closer together, you're more likely to run into storage or compute bottlenecks. So by having a common price abstraction, you're allowing each instance to decide what is the best trade-off for them to run and this is really what runs in our engine, this constant trade-off between various constraints that you move them as close as possible without causing or by preventing a computer and storage bottleneck, but minimizing, for example, network latency. And there's a number of other trade-offs between public cloud costs and how do you provide the most compliant resources but scare your infrastructure. So we actually are constantly resolving a multi-dimensional constraint problem across the whole data center by abstracting every business constraint into a price of a commodity and making decisions based on a combination of those. Okay, and of course, we'll be around if you guys have more questions. I'll be here and we'll be at the booth as well. We've got a booth on the marketplace, so feel free to come by. I'm happy to give you a more detailed and more deeper dive into our technology. Thank you.