 Good morning everybody. I guess afternoon now. It's okay, I'm good. Someone's paying attention on the right-hand side of the room. Welcome to the Cisco Sponsored Session. Welcome to day one of the OpenStack Summit. My name is Gary Kevorkian. I'm with the Cisco Events Team. Welcome to the Cisco Sponsored Track Room. We're going to get right to the meat of the matter here. I'm going to quickly introduce Mike Cohen, Senior Director of Product Management at Cisco, and our co-presenter from SunGuard, and they are going to be talking to you today about ACI and group-based policy and the things that Cisco and SunGuard are working on together. So with that being said, oh, one last thing. See how unprepared I am. Really focused. At the end of the session, you all got cards. As you came in, we're going to be doing a drawing for a Polaroid snap camera. The Metapod Group was a lot livelier, so you guys really got some work to do. So get your cards filled out. We'll be collecting them at the end. With that, I'm going to turn things over to Mike and ACI, Group-Based Policy Cisco and SunGuard. All right. Thanks a lot, everybody. I'm Mike Cohen. I'm Senior Director of Product Management at Cisco. I'm joined by David Graczynski, who's a cloud architect at SunGuard Availability Services. And today our presentation will be about how together we've worked together using ACI and how SunGuard is delivering their cloud services on OpenStack and how they've designed their solution, including some of our technology. We'll start by giving you an overview of the ACI solution and how it fits in the OpenStack environment and how you can use it and leverage the benefits of ACI. At that point, I'll hand over to David and he'll be able to talk about the SunGuard experience using this technology, how they designed their cloud, the challenges they faced, how they overcame them, and the end result and the solution they ended up designing and deploying now in production. Let me start by laying out some of the basic tenets of the ACI environment. ACI is built out of the Nexus 9000 series of switches coupled with the Application Policy Infrastructure Controller. The solution was designed to offer complete automation across both the underlay environment and the overlay environment to give you a complete data center automation and provisioning solution. It was also designed to give you deep visibility across the physical and virtual environment so that you can actually understand the operations of your cloud while it's running. But probably the most important part of the solution is this application-centric group-based policy model that we've designed into the heart of the ACI fabric. And really, the goal of that technology was to be able to deliver application agility, help you deploy applications more quickly, and really accelerate the time to move a new application from a design phase all the way to production and do it without compromising elements of security throughout the process. If we look a little deeper at what ACI offers, we can see it's a policy solution that scales across the physical environment, the hypervisor environment, including the virtual switch, the compute server environment, layer 4 through 7, storage, and even extends into multi-data center WAN environments as well. The goal of the solution was to be able to offer very deep security across the entire network fabric. The workloads can be placed anywhere and dynamically moved, and security will be applied as needed to the places where the workloads are instantiated. Moreover, the policy model is based on a zero-trust whitelist approach. And just this idea of using whitelist can actually solve upwards of 80% of your security problems right out of the gate. And again, one of the most unique and important capabilities of ACI is the ability to give you this physical plus virtual visibility, where we can actually show you at both a tenant level and an application level deep visibility and statistics about the workload, including health scores, latency, packet drops, where workloads are placed and how they're mapped across the virtual and physical environment to ease in your troubleshooting environments. And one of the key areas where we've invested in the ACI solution is around OpenStack and actually tying the OpenStack environment into our API controller. And one of the new technologies we actually offer now with our ACI solution is the addition of our OpFlex protocol and more importantly our OpFlex agent, which is now runs on the KVM hypervisor and can work directly with OpenVSwitch. OpFlex is a really important part of our architecture because it allows us to extend our policy domain and extend the policy control of APIC outside of the physical fabric directly into the hypervisor. This is where we get our physical plus virtual integration. Using these two components, we're able to offer a fully distributed neutron networking solution where we can handle not just layer two and layer three networking but also offer things like distributed DHCP, distributed metadata services that are critical in the OpenStack environment and we can offer through our collaboration with the OpenVSwitch and our network fabric. But on top of this, we give you all the visibility characteristics ACI can offer and make those available and easy to correlate back to the OpenStack environment which you've created. So now we're acting as an operations panel for OpenStack and we're working with a number of OpenStack partners so that we can take these solutions to market. One of the key areas of contribution that we focused on with the community is around group-based policy and you'll hear more about group-based policy as David goes into his talk because it's been part of the technology that SunGuard has deployed. The inspiration from group-based policy came from work we did with ACI. We had done a lot of thinking about policy, how to think about applications, describe applications and they were part of our design when we ultimately made ACI but the policy model itself actually has nothing to do with any of our products and we realized it would benefit the entire community to actually have it exist as a capability with an OpenStack that can work with anyone's neutron plug-in in any environment. So that spawned the project around group-based policy. A complete open source implementation of policy that can be used for capturing network intent. If you look at the ACI, if you look at this group-based policy model you'll actually see that we've introduced this concept of a group. This is a little bit different than a neutron network. It's designed to fully encapsulate the properties of the network endpoints within it and we use something called a rule set to describe how those endpoints will communicate with each other. So the group-based policy model is something that we've been working closely with the community around and it's something we use very much in our ACI products. Of course we have numerous solutions and we also support a standard ML2 plug-in but we find many of our customers are interested in thinking about policy differently and using it as a way of deploying and accelerating their applications. So now let me talk specifically about ACI and OpenStack and some of the benefits that can be accrued in running these environments together. The first one I mentioned is this idea of being able to do distributed scalable virtual networking really taking all the components that you would run in your neutron environment and being able to distribute them across both your compute nodes and our network fabric. This includes things like layer 2, layer 3, distributed metadata, distributed DHCP, distributed NAT so that we have no single gateways or single points of failure in our environment. We're able to offer hardware accelerated performance and we can do all of our VXLand tunneling at the top of RackSwitch without paying a cost inside our servers for this capability. We also give you this operations and telemetry. So from OpenStack you can correlate your OpenStack groups or your neutron networks directly into a view of the APIC and we can use all the APIC troubleshooting capabilities to manage and monitor that environment. We give you an integrated overlay and underlay environment to easily, VRAPI, bring up your underlay networking and manage overlay networking through a single pane. That includes tying in things like physical servers directly into your neutron networks through a single API. We have a number of capabilities around service chaining. Some of them were developed through the community of group-based policy. Some of them are specific on top of APIC and we give you a number of options about how you deploy them. Finally we can offer you an added degree of security where we can actually enforce security not just at the V-switch layer for the overlay but also at the physical switching layer. So we can actually even be resilient and secure in the case of a hypervisor being compromised. At this point I want to hand over to David and I want to give him a chance to talk about how SunGuard is using ACI and OpenStack and talk more about the challenges they've had and how they have solved them in building their OpenStack cloud. How's everybody doing? So as Mike said, my name's Dave Grisanti and I'm a cloud architect at SunGuard Availability Services. I'm going to talk a little bit about GVP and what SunGuard is doing with OpenStack. So a little bit of background about SunGuard. Most people have probably heard of them. We're big in the DR market. That's kind of the bread and butter. But there's a lot of other companies, you know, we're getting into the cloud space and have been in there for a while. But in the last year or so have made a big push towards OpenStack. And Cisco's been a big partner in that journey. So I'm going to go over a little bit of what problem we're trying to solve and what our typical customer looks like. So our customers are in the 80% is kind of what we call them. So they're not people who tend to use something like AWS like a traditional public cloud. And they may not necessarily be companies who need a ton of day-to-day hand-holding and only want a public cloud. So we're looking at, you know, larger IT companies looking to control month-to-month spend, term and commit usage-based billing, much more of a pet versus cattle model. Things like SharePoint, SQL Server, SAP, Oracle, bigger applications that are running on legacy IT infrastructures that are looking to help SunGuard help them move to the cloud. So again, shrink-wrap applications, limited automation due to time and talent. But they still need access to non-cloud and non-internet SunGuard services. So there's a lot of people looking for what we call hybrid. They may need connections back to their physical data center, back to COLO stuff that SunGuard may be hosting. And one of the differentiators that we're looking for is offering this mix of managed and what we call self-managed. So self-manage is more or less public cloud. So we give them an area to play in for dev tests with APIs, and then we have an area where SunGuard manages, which is where their production workloads are running. So by utilizing one platform, OpenStack, to give them both, you know, we get the best of both worlds. So their platform expectations from this is cloud-native and traditional networking models. So we've got some people who still are running static IPs on all of their VMs when they want to move inside and some that are, you know, happy to get a public IP address on the internet and host their application there. And also looking for above-the-hypervisor services. So VPN, firewall, load balancer, and through the use of ACI, using service and servicing or service chaining with these advanced services. So a little bit about what Cisco and ACI bring to the table for us. So policy-based automation, GVP and API offer managed, you know, pretend network service and service chaining, like I mentioned, with the above-the-hypervisor services. Distributed neutron networking, multi-hypervisor is a big thing for us. So right now we're KVM only, but in the future we're looking to offer VMWare as well. We offer that in a lot of other environments at SunGuard and it's a big thing that customers ask for. They're comfortable with it and they're used to a lot of their VMWare environments. And also just standardizing networking at SunGuard on this platform and also on ACI is a big thing for us. You know, we were to, I guess, step back a little bit. We were a big ACI user, even pre-Cloud Stack, so that was something that we chose to stay with as we moved into the open-sex space. So I guess concentrating a little on the SunGuard customization is just from the open-stack side. We chose to utilize Horizon. It gave us a lot of the, just out-of-the-box APIs talking to all the open-stack services. Then we decided to add branding and billing on top of that and also integrate some custom features in the UI without having to necessarily change the Horizon codebase. So that's been, you know, an interesting project, keeping with everything upstream so we get all the advantages, but, you know, being able to add our own dashboards. And then one of the other big pieces is Keystone V3 and multi-domain support. So I'll talk about this a little later, but we're running Juno now, all components, except for the UI, which is on Kilo. And one of the biggest challenges I think we had was getting all the multi-domain support into V3 support to work the way we wanted it to. So mostly we used upstream patches to get that working, but we did have to make some changes to Django OpenStack Auth, which is the authorization piece in Horizon, which handles Auth through Keystone, and also some things within Keystone itself to get our single sign-on working. So one of the big things from the beginning that we wanted was a truly single sign-on, you know, UI. So this morning during the keynote, I was showing that like, you know, username and password box and you see that and you say, what am I supposed to do with this? I don't know. Our customers expect to see the same single sign-on UI they get for all the rest of our portals, and we were able to offer that, but it took some beating against Keystone to get it to work. And then the multi-domain support in Horizon same way. It was kind of there with managing project and domain tokens, but we did have to make a couple changes, pull in some patches that aren't entirely upstream yet to get all that working. But in the end, it got us what we needed. And another kind of key feature, I mentioned the deterministic billing and usage-based billing at the beginning. We've chosen to rebrand the word projects and call them workplaces. And along with all of the virtual resources that come with projects in OpenStack, we give the customer this concept of budgeting that ties back to the metered billing. So in this example, you know, we see a couple of workplaces that represent either different kind of verticals in the company or maybe different departments. And admins within the projects can set a budget and then they can track their spend day-to-day as it moves towards that budget. The budget's not intended to prevent them from doing anything we use the quotas for that that are available in OpenStack, but it does give kind of an IT admin a good way to say, you know, I have five companies or five, you know, groups within my company, I can spread my budget across them and track how they're spending money. And getting this piece, not necessarily the budgeting, but getting the control for IT admins was a big part of Keystone V3 and the multi-domain support. So it's not really shown here, but one of the big things we wanted to let companies do was manage their own projects. So in the traditional V2 model, you know, there's one kind of OpenStack administrator sitting behind the scenes that's creating projects and assigning people to them. And again, something that was mentioned this morning. In our model, we kind of added another layer in between the OpenStack admin and the product admin, and there's like a domain admin that can add users, create projects, assign users to those projects, and that way they don't really ever have to call us. They've got full control to manage all that stuff themselves. And then, you know, because it's multi-tenant, there's isolation between projects within a given domain and other domains. And then the lifecycle of the workplaces is not always like this, but typically, you know, you use workplaces for DevTest and then you're using one that's, you know, a kind of lockdown managed by SunGuard. So we made a couple changes with the policy engine in OpenStack tool, not changes, but just customizations of the policy files to allow us to block certain APIs from certain workplaces so that customers can hand control over to us so they can't, you know, destroy VMs or stop VMs or make any changes in workplaces, but other ones are open. So there's kind of a control at the workplace level with policy and with roles. So as I mentioned before, so the tool set for us is Juno, except for Horizon, which is Kilo. Most of the components we're using are the standard ones, Nova, Neutron, Glancinder, Keystone, obviously, Solometer, we are using Mistral. I'm not sure how many, not a ton of other people are using that in Heat. And the biggest change with Neutron is the group-based policy piece that Mike had mentioned. So that's reducing a lot of the traditional API calls, building standard Neutron networks, making security groups. Your interface is really the GBP model, that abstraction layer on top of Neutron that allows you to build much more of an intent-based networking model instead of necessarily having to understand how Neutron works. And from the Cisco side, so APIC ACI integrated GBP, VXLAN on OVS with Plex Control Plane. So I mentioned this that we were an existing ACI customer, but we also are able to get a lot of run-of-scaling problems using VXLAN and OVS and take advantage of a lot of the features that it offers on the hypervisor like NAT and pushing a lot of the policy down directly to the KVM host. And from the advanced services side, we've got three pieces now that are kind of a mix depending on what type of workplace you're running. So ASAV for the premium firewall, BIOS for the open source firewall, and then we're using HAProxy for load balancing on both the managed and self-managed side. So what did all that get us? So an OpFlex-enabled, APIC-controlled ACI fabric orchestrated by OpenStack. It's kind of our buzzword. So that kind of covers the networking and the OpenStack piece. One of the other things I wanted to talk a little bit about and touch on is, I guess, our sense of HA, which can mean a couple different things, but our controller architecture on the OpenStack side is a little different to the standard model that's, you know, if you buy Red Hat's OpenStack and you just install it, you're going to get something much different than what we put together. So we did this for a couple reasons. You know, isolation for security to isolate certain services to the public UI, but traditionally you get, you know, the controller model is three controllers with all the services running on the same three controllers. We split this up so we can isolate some of the services available from the public internet and then things that only need to be accessed from behind the scenes. So you'll see over on the left, on the public side we've got the public UI servers, that's where Horizon's running, and we've got an onboarding application for our customers that's running there, Puppet for our managing our guest VMs for customers, and then public API servers are running. As many of the API services we can run independently. So some of them can't be separated, things like Keystone and Neutron and Heat, but where we can run public APIs and give customer access to them, we're running those on the public side. And then from the control side, we've also separated Rabbit and the database from the traditional OpenStack services. And then even our own Sun Guard controllers that we're using to do some of our managed services, those are also separate. So this is nice because it gives us much more control over the network design, the network flow, but it also creates a lot of challenges, most of which is centered around logging. So debugging when something goes wrong is a pain sometimes because we're running the API on three different internal servers and three different external servers. You've got to really understand the data flow when you're seeing a failure. The UI is calling the public APIs, could fail there. Is it sending off to some service that's only running on the internal controllers? So we're taking this as is now and looking for ways in the future to improve it and kind of get around some of our operational challenges, but it was something that I wanted to point out and just briefly mention. Okay, so I wasn't sure how this was going to come out. Colors are a little funky, but I think you can read it. So this was kind of our reference architecture for the three different, not types of customers, but maybe the three different types of workplaces that we have in the services that you can offer and something that we're doing with ACI. So the gray is a self-managed customer that only needs access to the internet. So on the bottom you'll see their firewall, their repair, and any GDP groups behind that. And then they're connected up into the fabric through on the shared L3 out, which is represented by the internet there. And then that's connected up to a shared segment on our core. And then the yellow is a similar customer. They need access to the internet, but they may also need access to some hybrid services, so something back either in Sun Guard Colo space or something on-prem on their side. So they get access out to the shared L3 out for the internet and then independent L3 out that we create for them for hybrid access. And then the last one is a mix of all three. It's internet, hybrid, and then also... Yeah, then it's Sun Guard managed services. So basically that's us being able to offer you know, antivirus, patch management, all of the Sun Guard managed services piece, and that's also shared. And then the other big benefit of ACI here and what we're doing is that we can kind of break these lines or add them without touching the customer's environment. So if we build the gray customer first and then we say they want to become like a yellow customer, we can add a hybrid in later. We can change the routes for the VMs behind their firewall so that they can go back to their data center without actually making any changes to their firewall, making any changes to their VMs. Same thing with the managed services. If they decide at some point that they want the services or we need to start monitoring their VMs for them, we can make those changes and get access without necessarily touching their environment. So I touched on this with the controller architecture, but I just want to touch a little bit on the team at Sun Guard and how we're supporting it and what we look like. So we're building and supporting a bunch of labs and five production sites right now, soon to be seven or eight. So we've got a really good team, multi-disciplinary. We've got a mix of software people, systems, both on the infrastructure side and the network side. And everyone works together. We're not necessarily separated in silos. And having people from the software side that understand how Python works and how OpenStock works has been a huge help in kind of jump in and fix things, especially when it came to a lot of that Keystone stuff. I worked on a lot of that. I've got more of a software background, so that helped when necessarily we can't just ask someone in the community, we can ask them for help, but they can only go so far. It makes a lot of difference when we can make code changes and present them back ourselves. And as I mentioned, just having all those controllers finding the source of the problem is different. The spirit controller architecture makes that more challenging, but our team does a good job at isolating problems. And then just to show our common and contributing back. So we've not been contributing a ton of stuff back right now. We've been working on most of that stuff through Cisco and through One Convergence is another one of our partners along with Cisco that's helping us with the above the hypervisor and advanced services. So most of our interaction is through them, but I think as we kind of build this stuff and we get out of site build mode and back in more into building the platform and adding more features, we'll definitely be looking to start contributing. So I mentioned... Yeah, this was saying, where are we now? I mentioned the five sites before, so North America and Europe, and hopefully seven sites globally by 2016. And one last thing before I stop and we take questions. On Thursday, we'll be doing a hands-on lab, specifically with the L4 through L7 services with the help of Cisco One Convergence and going through a lot more of how this stuff is built and showing other people how they can use it. And we'll, at the very end of that, do a little demo on the HA piece with the ASAV as well. Stop there and take questions. Oh, I said to remind people, use the microphones on the left and right, and there might be a microphone being passed around. And they've got Qs. They've got As if you've got Qs. That's the way it's supposed to go. So questions from... Are you using the dynamic SDN capabilities among the sites, the five global sites, or just within each site? In ACI? Yes. Just with... Yeah, we're not doing it. There's nothing cross-sites. Yeah, everything's isolated to a single site right now. I guess I didn't even mention that really with Keystone, but all the customers right now are represented one site. At some point, we're going to look to give them access to multiple at the same time, but everything's isolated to one. So what's your migration path going forward to other versions of OpenStack? Is there any reason to do that? There's definitely a reason to do it. So we're already feeling pain, but there's a lot of features we need in upcoming ACI releases and in just upcoming OpenSec releases. Controller architecture makes upgrading a challenge. So yeah, it's something that people that are also at Sun Guard here at the summit are looking at, kind of hoping to pick up tips from to do the upgrade. But yeah, I think... And I don't know how incremental we'll really do. We may just jump to Mitaka. But yeah, we definitely need to move beyond Juno. Have you had a lot of requests for customers who want to span multiple, I guess maybe your data centers, but connectivity among those data centers from an HA perspective and those kinds of things? We've definitely had requests for connecting... Most of the customers that come to us now want to be on OpenStack or in a virtualized environment, but they also want connection back to some physical piece, whether it be because they've got a, you know, load balancer with a lot of custom rules and stuff that they want to just move over and they want all traffic to be routed through there. We haven't really had any requests for HA across that. It's mostly like they'll have an isolated... They'll have an application running in the cloud and then maybe some stuff running in their office they want to keep connected. But nothing crossed the two, and at least not yet. I was curious what your process looks like for pulling in upstream patches, running in this production hybridized environment. Who signs off on that? So I guess from the... I guess we kind of treat them differently. The UI piece we control entirely ourselves. So any changes that, like if we see a bug in Horizon and we want to pull it in, I'll usually just find it, pull it in, and we'll push that out with our next release, have QA test it. And especially since we're running Kilo, we're a little bit ahead of where we are with the rest of the components. From the rest of the component side, we are getting, you know, packages from the vendor we're using for OpenStack. Assuming it's approved by them, we can usually bring it to them, get a service exception and have them sign off on it. But from our side, if it's something we think we need, we kind of just sign off on ourselves. We don't need a ton of approval outside of that. But we are using a supported version. It's not just pure open source. Anybody else? I guess you guys covered it all. Mike, Dave, thank you very, very much. Thank you.