 All right. Thanks, everyone, for joining me in the demo theater. The session today, the title is See Your OpenSack Network Like Never Before. And we're going to discuss some new visibility and monitoring functionality for OpenSack networks. Just before we jump into the session a little bit about myself, my name is Valentina Larga, and I work for Plumgrid. Plumgrid is a software-defined networking company that has a neutral plug-in for OpenSack. And what we do is we provide micro-segmentation and networking functionality for multi-tenant, private, and public clouds. And we have a very unique distributed data plane technology that we have open source back to the community that it's called the Iovizer. And we bring a comprehensive set of networking features and functionality. And I personally have been part of the OpenSack community for a number of years. My very first summit was in Santa Clara many years back. So it's awesome to see how we've grown as a community. And I work with a lot of customers on a daily basis, helping them understand how to take OpenSack as a technology and the ecosystem of products around it and build solutions that will accelerate their business. So just a quick note on what we do so that I can set the stage and get you guys to understand where I'm coming from. So the product that we've had for OpenSack for a number of years is called Plumgrid ONS. And as I said earlier, it's an SDN solution. It's based on overlay technologies. So it's a software-only solution. The leverage is a software data plane that goes inside each compute node. It can deploy on top of any physical infrastructure, any hardware, any networking gear, and brings you these isolated, multi-tenant environments, what we call virtual domains. Inside a virtual domain, you can define any networking functionality for an application. And you can define a topology, that it's a logical topology. And in software, it will make that happen on top of your physical infrastructure. Now, we're obviously an abstraction layer on top of an already existing physical network. And we work tightly with the OpenSack components. So we work very closely with all the key OpenSack distributions. In fact, we are the most integrated SDN solution. We work with all the major distribution so that you can very easily take OpenSack and then add the SDN layer on top. Now, as I said, we've had this product for a number of years and we've witnessed the adoption and the growth from the early lab kind of proof of concepts environments all the way to large production deployments that we have today with our customers. And when you work with customers on a daily basis, you understand that the challenges and the needs evolve from the beginning when it's all about just exploring the technology, understanding how all the pieces come together and what they can high level do with that to actually go in and deploy OpenSack plus the virtual networking layer in production. And the key requirement, it's all around operations. How do I operate this environment? How do I get visibility into it? What if something breaks? What if I need to go and figure out what component it's misbehaving? Now, as I said, I'm lucky enough to spend a lot of my days with customers. And so what I did when we embarked on this journey of creating operational tools and visibility tools for the networking component in OpenSack, I asked them, so what are the key challenges that you have today? What are the key challenges that you face today when you go and try to troubleshoot your OpenSack environment? So the first one that came from them was the lack of visibility into the virtual resources. Obviously, historically, there is a lot of tooling that has been built for the physical infrastructure, especially for the network, right? But many of those tools cannot be easily taken and as is used to monitor and troubleshoot the virtual infrastructure. To add on top of that, many of the troubleshooting exercises that you go through require actually some formal correlation between the virtual layer and the physical layer. Most common scenario, most common request that I hear from customers is, my two VMs cannot ping. Even this very simple troubleshooting exercise means that I go from a VM to the server, I need to map it to the virtual network, map it to the physical network, traverse both back into the physical, back into the virtual. You can see how I'm traversing all these layers of the stack. So the second need for all the customers we'd work with is how do you provide correlation between this virtual layer and the physical layer so that I can easily move between one and the other? The third, it's the lack of real-time information, heat maps, real-time health status. Again, historically, the network has been monitored with sampling and looking at historical data and figuring out what happened in the past. Well, now in this cloud environment, we want to know when something is happening, not when something happened. So real-time information is crucial to go and perform that task. So what we did is we went and looked at why it's available out there. What are the tools that others have built to look at the open stack environment and especially at the SDN or a networking layer in open stack? And a lot of the tools out there have a very traditional look and feel, something that maybe will look familiar and normal to you which is lots of tables, lots of rows, lots of data information presented, really hard to spot a problem. So a lot of the exercise of actually troubleshooting an environment is left to the user. We need to go and figure out, oh, does this row here mean that that entity, whatever it is, it's experiencing some issue or not? A lot of times, based on agents, right, they're trying to monitor your infrastructure so can really only look at a simple, small percentage of data. So when we embarked this journey, we wanted to take a novel approach. We wanted to redesign how visualization and monitoring and troubleshooting will be performed in an open stack environment. And we took into consideration needs of the customers, we took into considerations what has been done until that point and we designed something completely new. So just last week, for those of you that are actually following what we're doing as Plum Grid, we announced this new product that I'm happy to share with you today. The name of this product is Cloud Apex. And as you can see from the name, it really helps you look at your open stack environment from a new, completely different perspective, point of view. What Cloud Apex does for your environment is that it brings a cloud visualization platform that gives you real-time, health information about both your virtual and physical resources. It's based on three key pillars. The first one is that it completely redefines how visualization is presented to the user. So just taking a step back for a second, Cloud Apex is designed to be used by both cloud operators. So those users that are pretty new to the product and technologies, as well as an additional troubleshooting tool by the cloud engineers. So someone that is instead very familiar with the ins and outs of each component. But nevertheless, what we did was to create a design that would be unique and intuitive to try to make it very easy and simple for anyone to just jump in and figure out something is not right in that environment. And we made it such that it would be user configurable, as you all know, my definition of healthy might not be your definition of healthy and might not be your definition of healthy. So how do I enable someone to actually go and profile the environment first, learn what it's normal and not normal, and then go and set up all the monitoring infrastructure to react to that behavior that it's now incorrect. And last but not least, as I said earlier, we wanted any person in an operation center to be able to open this console and with a quick look find out, okay, that one resource is experienced in some issue. So we wanted to make it very intuitive and completely decoupled from the underlying product. Again, you don't have to be a ninja of any of the technologies underneath. So I'll show you in a second the demo, but as I walk you through the demo, I want you to keep in mind these five key highlights, five key features. So the first thing is that we're bringing the concept of affinity-based GUI. So the ability to select any resource, whether in the physical or in the virtual world, and to be presented with its relationships with any other resource in the environment, making it very easy to perform correlation back and forth from the virtual layer to the physical layer and the opposite. The second big group of features, it's the ability to layer real-time held status information, what we call heat maps. So on top of any of the views that we're building, and today I'm just gonna show you one of the views, we can turn on heat map information. This is what it's configurable by the user. You can then look with a very quick glance at the environment and figure out exactly what component it's experiencing issues. The third part is around the ability to again correlate and search for information in the environment. So what we call the cloud-wide search functionality where I can enter any pattern, any string of characters, and look for information across the resources, the real-time logs, and any of the heat map information. And last but not least, troubleshooting functionalities. I'm just gonna touch on that, but what we've done is we built a very comprehensive portfolio of tooling at the virtual network infrastructure layer. So a lot of things that you would do on a physical network like trace a packet, or do a tap, or these sort of things like TCP dump, we enable you to do it at the virtual network layer. Now all of these, it's empowered by the fact that we have a data plane component that it's programmable and capable of running, tracing, and monitoring functionalities right in the kernel. So none of this, it's built on agents or sampling. It's looking at every packet that traverses the kernel inside each compute node and can present this correlating information back to the user. Okay, now let me show you a quick demo. Perfect, so in this demo here, I'm logging into my environment. I'm connecting to one of my OpenStack deployments, and this is what the user is presented with. So at the top left corner, I have all my virtual resources. Now in Plumgate terminology I said earlier, virtual domains means tenant environment, so I have my tenants. I have my virtual machines. And at the bottom, I have my physical resources. So I have my racks of servers, my servers, and again, my virtual machines, which obviously exists both in the virtual and the physical layer. And on the right side, instead I have detailed information about the environment. Now you can see the look and feel it's quite different, right? There's no tables, there's no rows of data. Everything is presented in this graphical fashion here. And I also have all the real-time logs, that come from the infrastructure. At the top, I have a quick summary of the conditions of the system, with the top alerts and logs. And if I want to download and export some of the information, I can also access it in a tabular format. So if I want to go and export it into Excel, for example, or any other tool that you might be using. Now, once I'm logging into this environment, what I can start doing is I can start correlating resources back and forth. So here, as you can see, I'm selecting a resource on the virtual space, a virtual machine, and I'm presented with information on where it sits on the physical environment. So I can immediately know which server that virtual machine is sitting on. And I also get all the detailed information on the right. I can do the same for a tenant. So I'm selecting the entire tenant environment, what is 50 virtual machines there. And I can see for each server, how the virtual machines are mapped into that physical environment and how they're connected together. And same from a physical layer, say that I want to know which machine I actually deployed on top of a physical server, I can get the reverse information. So this affinity-based GUI gives you the ability to very quickly and effectively correlate these two layers back and forth, as well as to extract from the infrastructure all the information that are relevant to those components that I've selected. Now on top of this view, I'm going to enable my heat map. So the heat map configuration is very simple. I have a menu of metrics. Right now we picked a few of those, but there is tense and tense that we could be enabling there. And as a user, I can go in there and select those that are relevant to my environment, as well as set the thresholds that are relevant to my environment. In this example here, I'm setting up bytes, Rx. I'm setting up an alert and a warning threshold. And we also have this feature that we call a gradient. So what a gradient does, it's going to color resources from dark gray to white to signify how far they are from crossing the alert threshold, all the way to being very close to being in alert or warning threshold mode. And as you can see here, you can layer any of these metrics on top of your resource view. So I can choose any of the metrics that I have here. I can apply those metrics at the virtual machines level. So each individual tiny component, or I can also look at the health of my tenants. This is very important for a cloud operator. I just want to get a feel for how each tenant is behaving. So this gives you that visibility right there. I can also do the same at the physical level as you see at the bottom. Now the last feature is the ability to order by criticality. So if I order by health status, I get presented with those resources that are in critical state first, and those that are instead in normal conditions less. So I can very quickly go and act upon it. Obviously here I set my thresholds very aggressively because I wanted to give you guys a view of all these colors changing. You wouldn't have these many, right? You will have a couple of entities probably in yellow state, but it's just to give you a feel for how this is working. Now what I'm doing next is I'm showing you how I can search across the resources and the heat map information as well as the logs and all the real-time information that I have in the system. And I can search for IP addresses. I can search for UIDs. I can search for MAC addresses. I can really search for any field that we have access to. And this is very important because as an operator they often don't have access to their open stack environment. So they just want to be able to go in there and search for a specific tenant name and pull out all the records that are relevant to that specific environment. And all of these, as I said, it's real-time coming directly from the open stack components, coming from the SDN layer, and coming from the physical network environment. Last but not least, obviously once you've monitored and you've figured out that something is misbehaving, you want to go and act upon it. So the first thing that I'm showing here is the ability to go and look for logs. These logs give you visibility into the environment. They give you visibility into the components. And once more you can filter by a specific entity. You see it's very simple to gather monitoring information here. So this was what I wanted to show you today with the demo session. And we're at the Plumgrid booth which is in that corner there. And I'm going to be hanging around a little longer. So if you have any question or feedback since this is a new product, I would love to hear your thoughts and comments. And if there is any question from the audience, I'm happy to address the end of that here as well. Sure, I cannot hear anything. So because this is a kernel component, did I hear well what is the heat, the in terms of performance you mean? Yes, so because this is a kernel-based monitoring and tracing, I actually have zero performance hit on the system. There is a middleware component that is dedicated to correlating all this information that then presents it to the user. But from a VM and compute layer and networking layer, this has zero impact. Again, because it's not agent, we're not sampling packets. We're not spanning components. This is just, every packet traverses this tracing and monitoring layer and we can extract information out of that. Any other question? All right, thank you so much and I'll be hanging around a little longer if you want to chat more. Thank you.