 OK, welcome, folks. So if you want, you can come up closer, make this intimate. And any of you going to the Mirantis thing at 4.10? OK, a couple of you. We're concerned that we had to get done right before then, in case people want to run to catch the bus. So just quick on introductions. I'm Doss Kamhout, principal engineer in Intel IT. I'm Malini Bandaru from Indus Open Source Technology Group. And we're happy to be here with you this afternoon. We're going to have another number of other folks from Intel coming on, talking about some of the deep dive on some of their specific areas. But our intent today is to give you an overview of what Intel's doing with OpenStack as part of the community and our contributions in our deployment. So we'll just jump right in. So for those of you that don't know, Intel has a long history of being a contributor to Open Source. We're one of the top contributors to Linux. We bounce between number one and number two. This slide says number two. We're actually number one from the kernel perspective right now, a heavy committer and contributor into Android, HTML5, and with OpenStack, we're actually a top contributor as well. So what we're going to cover today is we have contributions. So most of the focus of the topic today is going to be the specific contributions that we're making. So this is across many OpenStack projects, various Open Source tools. If you look at Stackalytics, which is what RANT has put together for viewing the contributions, you'll see we're a top contributor to Grizzly and Havana. And your team focuses quite a bit on optimizations. Optimizations, anything to make Intel hardware shine? So if we have a special hardware feature for encryption decryption, we make sure it's visible to the OpenStack scheduler and things like that. And we're going to go quite a bit into those in a little bit later. And so my job is I work in Intel IT, and I develop and I run cloud environments. We've been using OpenStack starting in the labs in 2011. And I'll talk a bit more about that. But we see it as a single control plane for all of our infrastructure. And then we also have Intel Cloud Builders. Anything you want to share on Cloud Builders? That's our reference implementation. So our best practices that we'd like to share with you. So that's our open source effort too, there. I think the last time I checked, there was like 70 plus reference architectures that you can use, probably growing all the time. But basically how you take various solutions, turn on private clouds, and other capabilities to build a cloud. On that note, we had recently some students come up and try using the cloud right out of the box, install it, create a teaching app to use the cloud to do some math applications. They'd never done anything. REST API was always an Android type of plugin application. So we've been helping students use the cloud too now. So what we see in the data center space, and this is both in large scale data centers from a cloud service provider as well as traditional IT. And especially on the traditional IT side, we see networking as a major bottleneck in regards to getting things stood up. So fortunately, we have things like Neutron changing this. But it's typically two to three weeks to provision new services. That's from somebody requesting to actually getting those online. This is very, very common. Used to be the bottleneck was getting a server. That's mostly changed. We all see this massive growth in regards to storage. So this is both from video as well as unstructured data continually to grow inside of the data centers and basically take on more space and increase the complexity of the environment. And on server utilization, so a lot of us in enterprise shops and IT shops, and probably even if you look at a large scale cloud service provider, average utilization is under 50% despite virtualization happening. So lots of new challenges are coming and opportunities. So this isn't just an Intel vision, but fundamentally we all believe that the infrastructure should become software defined. So allow it to be composable. Allow us to have automated orchestration. Introduce a lot of intelligence into your data center so that you can basically run at a larger scale, deal with virtualization, and basically operate stronger from your IT shop perspective. So there's a couple pictures here. See if a couple are taking pictures of it. But it's fundamentally, this is just an example, from taking networking to be a new service into months to can you get it in minutes. So a key component of OpenStack is the fact that you're turning everything into be software defined. And I'll jump into the Open Data Center Alliance cloud adoption roadmap, and just real quickly here because we have a lot of content we're gonna cover. But this is a roadmap that we see a lot of enterprises moving down the path of. If you spend any time running an OpenStack environment or a contributor to it, you'll see there's a distinction. Folks like Randy Baez, he's the concept of pets versus cattle. If we ever do a summit in India, that term won't work. But fundamentally, if we call it cloud aware apps and enterprise legacy apps. So how do we support these in our environment? So basically enterprise legacy apps, they're still being built today. They require resilience in the infrastructure. Meanwhile, cloud aware applications are scale out. They allow for failure underneath them and they're usually built to run at global scale. So if you see somebody like a Google, they rarely go down, they write their apps as cloud aware. Most consumer apps are being built this way. But what we wanna point out, and this is actually an enterprise roadmap from the Open Data Center Alliance, is this point towards the end. There is a goal of this federated interoperable and open cloud. If you listen to a lot of the key notes, you hear the word interoperable probably 20 times in each one. And obviously we're here at OpenSAT conference. So Open is huge. And this is both from a public as well as a private perspective. So letting it drive forward to be an actual open environment. And Intel is definitely highly interested in this moving forward, as well as most of the attendees here at the conference this week. And then real quickly, I wanna also give you a perspective of what Intel IT does. So we said we're gonna cover our contributions, what we do from a deployment perspective. From a deployment, we've been running a design grid since the 1990s. This is approximately now about 60,000 servers across the globe. We call this Cloud's Uncle or Cloud's Mother. It has a lot of the same attributes that you'd see from a cloud. So self-service, resource pooling, measured services. And most grid environments are pretty familiar with cloud concepts. Back in 2010, we churned on an enterprise private cloud. And this now is about 13,000 VMs in our environment. This is across 10 data centers. 75% of all of our server requests come through the self-service portal. So people don't actually have to call IT. And this is highly virtualized, so 80%. And what we did in late 2011 was we decided to make a bet on OpenStack. We looked at all the various open-source solutions that were in the environment at that point in time. And we in IT said, hey, we're gonna make OpenStack work. We run an open-source private cloud since 2012. Right now this is about 1.5,000 VMs across just two data centers so far. And our first focus was on running cloud-aware applications. So things that we're able to handle scale out as well as no resiliency in the infrastructure. But this weekend, my team couldn't come here this week because we did a big upgrade and we just turned on things like live migration and boot from volume. The reason for this is that we can start handling those traditional apps, the ones that people call pets. And this is pretty important for us because it now allows OpenStack to handle these tougher areas. And one last point I'll make on our IT space is we see OpenStack as a single control plane. So we have numerous different types of use cases inside of Intel from the silicon design space that runs massive grids, from the validation labs, the control physical hardware, to our traditional enterprise hosting which is running various applications whether it's collaboration tools, whether it's various web tools. But the beauty of OpenStack is it gives us one uniform API set that allows us to handle all these use cases. And even better, it allows us to control existing infrastructure as well as new infrastructure. So yesterday I did a talk with Dan Wenlandt from VMware and it's pretty nice to see all the investments that VMware is making in regards to supporting OpenStack. And just right before here, I spoke on Microsoft and the fact that now Hyper-V is really connecting here. So we are hoping this would happen when we made a bet on OpenStack many years ago and we're seeing it true by everybody allowing the existing infrastructure to run as well as the new infrastructure that people are introducing, say new open source solutions that combine it all together. And we believe that this path will be working for many years to come. So we have some top challenges and it looks like I got the build wrong so let me just roll it through. So we're gonna be covering a number of these, right? So security and compliance, huge area. You wanna talk a little bit quickly on the tech challenges and the responses. You can have root kids, you can have BIOS insertions, anything that can go wrong, may go wrong. There might be an element out there who's gonna mess with your system. So that brings in trusted compute pools. Then there could be issues such as where you want your data to be stored. If you're a government agency, you might not want your data to exit from your soil. If you have tax liabilities, let's say in the US you're in the state of New Hampshire versus another state, you might have some tax exemption. So you might wanna save your data in such tax friendly states. There might be even restrictions on where you can do certain research such as stem cell research. So the data has to be resident in those locations. So that's where geo tagging comes in. Then with all encryption, decryption and making your system more secure, you need key management. So that was why our interest in key management. And last but not least, Intel's all about bringing you awesome hardware to make your systems run better and better. So we wanna expose that through enhanced platform awareness. And Ragu and Malini are gonna deep dive on all those. So you'll find out the specifics. And then we have unit cost reduction. So the point on the left is these are like my problems. This is an IT shop. I need to supply security and compliance. I need to drive a unit cost reduction constantly. It's how I'm measured and I need to have business uptime. So all these factors as well as there's a number of others like give flexibility and agility to my end users. But what we wanted to show is that in each of these areas we have technical responses, both as an open stack as the overall community. And we wanna deep dive now into some of the specific areas that Intel is helping with. So you wanna talk about many of our contributions before we pull Ragu up? Yep, we just wanna make a point that we're involved in multiple aspects of open stack. We're involved in Silometer, which is all your metering data. Not just to build your customers if you're a cloud provider, but also how deep and visible your system is. How much RAM consumption, CPU consumption, et cetera. We also wanna make your storage systems more efficient and we'll touch on that in a little bit. We're involved with your image storage and to make sure that they are valid, legitimate, good images, so they're certified images. I already mentioned the trusted compute pools, enhanced platform awareness, all that fits into NOVA. Already mentioned to you the key management system and block storage, we're very, very happy that the John Hopkins people came and said we can provide you encrypted block storage. Network services, we're really getting into this deeply right now, we have DPDK, we wanna enable the V-switch to use DPDK and accelerate your network accesses. So basically we're involved in the compute, in networking and storage and very soon we're gonna give you more and more information on that. Awesome, so let's go ahead and pull up Ragu. He's one of our sharp principle engineers. Let's give you this. All right, so how much time do I have? Four minutes? Sure, sounds perfect. I can do it. Hi, good afternoon, my name's Ragu Yeluri and I'm a principal engineer in our data center systems group and I drive security, path finding and development. Lot of focus on OpenStack and I'm gonna share a couple of things with you. There's a build here, so. Okay, how many heard the term trusted compute pools before? Okay, fantastic. For us, the overarching goal for TCP is we want to provide visibility, control and compliance in this abstracted, virtualized infrastructure called cloud computing. It gives you three things. TCP gives you three things. One, the ability to have a pool of logical servers that have attested to some kind of platform integrity. Okay, today the technology we use is called Intel's TXT. It gives you the ability to attest to the integrity of the platform on which the workloads are running. Okay, once you have this pool called trusted pool, you can do some interesting things with it. You can control where your workloads are running. You can control where your workloads are migrated. And at any time if your policy is violated, your VMs don't get created, they don't get migrated. And more importantly, you can provide this as evidence to your compliance tools, to your security monitoring tools. So when your auditors come to find out if your workloads are violated, any of the audit requirements, you have a verifiable measurement of trust that ties down to the Intel architecture all the way down to our microcode. Okay, we are in the process of creating a set of security controls with FISMA, with FedRAMP, with HIPAA, so that you can evaluate the trust of the infrastructure at any cloud provider on which you can run your workloads. I think for organizations that have sensitive workloads, mission critical applications, that last one is very critical, be able to prove to your auditors. A lot of this is available since the Folsom really is an open stack. We are adding one new thing to this, which is the notion of geotagging. And the idea is pretty straightforward. We're gonna write a secure descriptor into one of the modules on the motherboard. It's called the TPM, the Trusted Program Module. And that little piece of fingerprint is made available to the open stack scheduler. And the scheduler can then make decisions about the physical location of the server on which these workloads are gonna run. If it's a FISMA workload, for example, the US federal government workload, there is a very clear requirement in the FISMA spec that the US government workloads have to run within the continental US. But in a cloud environment, you don't know where the servers are. But this capability will give you the ability to know exactly which physical server and where that is physically located. This requires some changes to the open stack environment. There will be a new filter in the scheduler. There will be some changes to the horizon interface. There will be some extra specs in the flavors for this. And then there is an attestation extension as well. Okay, there is a blueprint for this available. I think it's rev one. So I request you guys to go look at the blueprint, give us feedback, and also if you think of use cases that you might use, this geo-tagging information, we would love to hear. Okay, one other piece of information on this. There is a NIST publication called NIST 7904. It is an interagency report that NIST publishes, which most of the time the community uses and most of the federal agencies use. So take a look at it. It talks about trusted geolocation in the cloud and how do you use geo-tagging. Okay, I'm gonna switch to an interesting concept that we are working with. Actually, the Citrix guys have been demonstrating this at the booth recently. The idea is you as an organization are gonna control the keys for the encryption and the decryption of the VMs. So when you put something in an OpenStack cloud, a virtual machine image, it is a piece of blob that's sitting there. The actual keys are in the key management server that are in your enterprise. So when OpenStack Nova Compute wants to launch the VM image, that's when it's gonna negotiate with the key management server that's sitting in your enterprise and saying, hey, I'm launching on this physical machine. Here is the ID of the physical machine, which is the TPM ID. Can you give me the decryption key from your key management server? And the key management server will make sure that the server on which you are decrypting is a trusted server before the decryption keys are released to it. So in this model, the only time the VM is in clear is when it's executing. At rest, in motion, up until execution time, the VM is encrypted and protected by the keys that you own in your enterprise. And if you want to get rid of all that stuff, all you have to do is delete the key and the key management server, and the rest of it pretty much is useless to anybody else. We had to do some extensions to Nova Compute for this. We built a key management server that resides in your enterprise. And interestingly, the key management server APIs are very, very analogous to the Barbican key management APIs that are being built. Okay? And this is a good segue to what we are doing with KMS. So back to Malini. Hi, guys. We're kind of rushed through the rest to meet that time commitment. We've already spoken about key management and pretty much, you've met it yesterday in the Barbican talk. Wow, that's loud, sorry. And we've seen how we can use it in different parts of OpenStack, not just to save your objects in an encrypted form, your volumes in an encrypted form, your VMs in an encrypted form. So anywhere and everywhere you want to have some security, you can use the key management to get your key and then encrypt your data and only release it based on your trust level. Are you the authenticated, authorized entity to be accessing that data? I just want to tell you about our Cinder filters. Sometimes you might have storage, all up the wazoo, cheap ones, fast ones, more efficient ones. So Intel has contributed patches to enable you to have diverse levels of storage and to deploy your application on the storage filter that meets your needs. So our filter contributions to that. This basically demonstrates that, you can say I want fast, I want storage A which has fastness, speed, maybe some kind of error correction and things like that. Another thing where Intel has contributed is data collection. You might have allocated storage and RAM and CPU and all that for your VMs and your hardware might be already pre-allocated but it's not being really utilized. So if you want to get more out of your data center, we can use utilization based aware scheduling. So if it's underutilized, go ahead, run another VM over there. So this just basically describes that, you have the API, you say I want a new VM, the scheduler goes and gets the utilization information before it actually schedules the VM. I already alluded to this, the enhanced platform awareness. We have Intel has a whole bunch of products each generation, we have wider registers, more instructions, we have the AES and I, coming down the road will be the SHA and I for secure hashing. So we wanna be able to expose all that so customers can say I want that because I am a secure application, I am doing a lot of encryption, I want that speed up and I want there for an Intel piece of hardware or AMD hardware, NVIDIA hardware, whatever that has those features. So across the board, we'll be exposing any platform enhancement features. Adrian. Thanks, Malini. So I'm Adrian Holman, I'm a software architect in the communications and storage infrastructure group. And two of the really exciting technology areas that we're looking at are the distinct but mutually beneficial software defined networking and network function virtualization. Now SDN as you probably know is that separation of data plan and control plan, often with a logically centralized view of your network. Network function virtualization is very much a service provider led initiative that's looking at how we take the wide variety of appliances that get deployed to drive the wire line and mobile network infrastructures. So we're taking those and we're gonna virtualize them. The combination of these two initiatives are really helping to drive some incredible CAPEX and OPEX reductions, also to help drive some new service revenue possibilities. Through the ability to introduce things in a much quicker fashion. The picture we're showing here on the left is showing really how a lot of these appliances are developed and deployed today. You've got these vertically integrated devices that are quite monolithic, oftentimes developed on proprietary architectures and solutions. And we're moving that to this right hand side, which is very much looking at a more open based infrastructure. We're leveraging industry standards or high volume industry standard servers where lots of open standards. And of course, a lot of networking within these compute nodes. So one of the technical challenges that you get from this fairly radical transformation and how we develop, manage and deploy these applications is that the networking requirements on these, what would you have traditionally looked at as compute nodes now goes up significantly. You need to be able to process data packets at a rate that's suitable for these type of virtual functions to be deployed. One of the things that Intel is doing to try to address that technical challenge is the development of the data plan developers kit. Now Intel DPTK is a set of optimized software libraries. It contains things such as optimized buffer management, classification capabilities, memory management, as well as these optimized drivers for pole mode infrastructure. The combination of all of these software components allows you to take packets from, let's say, an analytics system at least and take them up into user space at incredibly high data rates. In this type of environment, though, what we're seeing is very much a move towards an incredible amount of virtual switching and with these switching becoming a critical component of your network architecture. So we've taken that DPTK technology advancements and now we're applying them to the open virtual switch project. What we've seen by kind of removing or replacing some of that data plan element of OVS and putting in some of our DPTK technology, we can see a fairly incredible increase in the packet processing throughput that you can get. So it's in the region of a 10x type of performance improvement. As a result of that, we think with that type of performance we're helping to facilitate that transformation and getting these virtual appliances deployed on these industry standard compute servers. To move that into an open stack context, we're looking towards Neutron and the modular to framework. There's a lot of fantastic work that's happened with ML2 and you've heard probably in earlier talks today about the switch and there's another talk tomorrow about ML2 and how you integrate open V switch. So one of the things Intel are in the process of doing is developing a DPTK V switch mechanism driver and agent so that we can help to unleash that type of performance potential that we see possible with that DPTK type of solution in a Neutron managed network environment. The intention is that this code and the blueprints related to it will be released during the ice house design cycle. Paul, I'd like to invite you up to talk to some of the storage. Thanks, Adrian. All right, so I'm really happy to get a chance to come talk to you real briefly about really Intel's first really big contribution to Swift. And when I say big, I mean big both in size. This is a very large effort and we hope a very big impact as well. Impact by enabling new use cases and impact because some of the building blocks that we've had to put in place to enable this capability really enable a whole bunch of other stuff as well. In fact, this is such a big topic. I had to include a link down here at the bottom that covers really a 60 minute tutorial I did a few months ago at the Intel Developer Forum. Covers a little bit about Swift, a little bit about Erasure Codes and a little bit about the implementation. Really, what I wanted to do here to give you the super high level is walk through the put of an object or the writing of an object into a Swift cluster with the Erasure Code enabled. So for those not super familiar with the Swift architecture at a real high level, it's really two major tiers. So at the top here, we've got the access tier and this is where things like load balancers and the authentication service live and then a series of proxy servers. So in Swift terminology, a proxy server is responsible for fielding the incoming requests and deciding where to send the request to the backend. And the backend then is this collection of storage nodes here that we've got pictured where of course the media is and where you actually store the information. Now today with Swift, we only support one policy and by policy I mean replication, right? So typically it's triple replication. So if you were to write an object into a Swift cluster today, it would make its way through the proxy and the proxy would send it out to three different locations in the cluster or you could have a different number, you could have two or four. But the point is it's one policy for the entire cluster. So to do the Erasure Code work, one of the building blocks that we had to put in place was a feature called storage policies that allow us to have multiple policies within the same cluster to enable things like not only Erasure Code but a reduced replication tier that you could have a performance tier or a performance pool, a lot of similar type of things you see in other storage systems. So with Erasure Code what happens is an object comes down and it makes its way to the proxy. Whereas like I said today with triple replication that proxy would simply send that object out to three different locations. What we're doing now is we've included an encoder and that encoder in Erasure Code terms kind of like a big distributed RAID system but quite a bit more advanced and with a lot more knobs and features. That encoder is now gonna break that object up into multiple fragments and distribute those fragments throughout the cluster. Then when somebody comes along later and says they wanna get that file, the proxy is going to pull in a subset of the fragments and this is a key point. It doesn't need all of the fragments. And then a decoder is going to reconstitute the object or put it back together the way it was originally and return it back up to the application requesting it. So why is Intel involved in doing this? What's in this for us? Besides the fact that this is really super cool work to do. What might not be obvious is by implementing Erasure Code depending on the type of Erasure Code you choose we can really dramatically lower the storage footprint in the data center. So this really boils down to a total cost of ownership play beyond all the other cool stuff about enabling the usage models and reduced replication, all those kinds of things. But if you take for example, a triple replication cluster, your storage drive ahead is obviously 3x. And if you use a typical Erasure Code algorithm, we can reduce that to 1.5x, reducing the cost of the number of storage nodes you need, the amount of hard drive capacity you need, the power you need to power all that, the cooling you need, all that kind of stuff is lowered through this effort. So that's the super high level summary and I encourage you to take a look at the tutorial or go out and check us out on Launchpad or we have a trial and discussion board where we've got all the great details. And we definitely care heavily about that. So I talked about the three areas earlier, Paul, about unit cost and from IT perspective, three copies of everything is a great technology but getting this algorithm in Erasure Code, we're looking forward to it. Let's do it. So just to bring us back, I want to give you just a reminder of all of Intel's contributions across the board. So Ragu and Malini spoke to the security compliance. You know, you saw quite a bit there. On the unit cost reduction, both from a scheduler perspective, we saw pieces from Swift Erasure Code, a number of things that helped me from an IT shop perspective to lower down my cost and better optimize the usage of my data center. And we didn't spend a lot of time on business uptime but you shall be where things like Flex Migrate are already built into the platforms and can be utilized by the various hypervisors. So we talked about cloud aware versus enterprise traditional apps but these are fundamental capabilities that are built in already that you can consume in OpenStack to drive a higher level uptime of your infrastructure. So what we're gonna do is we have a few minutes left. So what we're gonna do is go ahead and take any questions and pull up the rest of the crew in case there's specific questions. Any questions from the room? Here, let me give you a mic. Are there any plans to upstream the DPTK code? So the DPTK OpenV switch, the question is are we gonna upstream DPTK OpenV switch? That's already available on a site called 01.org. It's an early version of the code. It'll be in continuous development and it's fully open sourced. But I mean like most of the distributions are like using the stuff from OpenV switch.org, right? Is there any plans to merge the code in the OpenV switch? Okay, so the question is will the DPTK V switch accelerated capability get merged into the standard OVS.org? So not at this time. We're working through a lot of the performance issues. It's something we'll look at in the future. But for now, go to 01.org to get the code. Thanks. Yes? It's actually in the same topic. You almost asked that question. So thank you for asking that question. So the following question is what do you need to try another driver if at the end of the day it's the same OVS? Sure, so the question is how is the code based on 01.org different to what's on OpenV switch.org? Why is it different? So the control plane is very similar. There are some differences in how we managed that data path into the VM. It's one of the key ways we get some of the performance differences. And because of that difference, we need a slightly different setup and configuration. But your key OVS config is unchanged. Hi. First of all, I'd just like to say thank you for all of the work you're doing with OpenStack. It's really quite extensive in many different areas. And my question is a bit from left field here. I'm just wondering since Intel is a large organization and is contributing in OpenStack in many, many different ways. Do you have any secret hints on how you can help your engineers interact with OpenStack upstream and how do you kind of get those teams talking about the work they're doing? Wait a minute. So you're saying our engineers are not communicating enough with each other? No, not at all. I'm saying we are getting fantastic contributions from Intel upstream. And I'm just wondering, how did you do it? Because some organizations have difficulties getting there. Very focused effort, right? We're thrilled that you think so. And we just want to say that we've had quite a history of open source contributions. We just kind of stick our nose to the grindstone, review our patches, update them. And we're glad you think we're being successful. Yeah, Intel has, people don't know, we have an open source technology center. We specifically drive and help across almost every, I don't know if you saw all the different open source projects that we work on. But there's thousands of engineers that work across the board to enable open source activities. And Intel has had history, both from a consumption model. Me as IT, I consume Linux and help drive Linux in the industry. Meanwhile, we had folks in our OTC environment, open source technology center, drive contributions in. So we, both from both angles deployment and contributions do it across the board. Very important to us. And we consume some of this ourselves too. So that helps. Any other questions from the room? Okay, so again, we just want to leave you with the point that we are making massive contributions as part of the community. You'll see even more from Intel moving forward. We're strong supporters in both deployment, as well as driving solutions into OpenStack. And we look forward to continued work with the community. So thank you all for attending. Thank you. Thank you.