 We are going to get started. Thanks for coming to this talk about building clouds, the Apache cloud stack. My name's Giles Sair. By day we're at a company called Shape Blue, we're a cloud integrator. My evenings and weekends are spent working in the Apache cloud stack community. I'm also a sufferer of a really bad cold today. I'm rapidly losing my voice. I've also managed to get the Shape Blue CTO Jeff Higginbottom to come along. Jeff is going to do his demo piece of this talk, just to save my voice as much as anything. First of all, Apache Cloud Stack. Hands up in the room before this conference. Who had heard of Apache Cloud Stack? It's about half the room at an open source conference. Who's downloaded and done any work with Apache Cloud Stack? One guy. The reason I've got a picture of the invisible man here is because Apache Cloud Stack is the cloud's best-kept secret. Apache Cloud Stack is an infrastructure as a service platform, but because it's an Apache project, it's not really talked about a lot. One of the great things about the Apache Software Foundation is that we have a really good governance model, not allowing vendors to take the project in any particular direction, but it may set sometimes a bit difficult for us to go out and evangelise and talk about our software. There's other infrastructure as a service projects out there at the moment who are gaining a lot more mind share, getting a lot more marketing news than we are, but Apache Cloud Stack is, hopefully I'm going to show you today, is today about the most solid, easily installable production grade infrastructure as a service platform that there is out there. Problem is, nobody's heard of it. OK, so let's look at what it actually does. So Cloud Stack is an infrastructure as a service platform. It's about taking networking, compute and storage and delivering that through self-service, either through a GUI to end users in some sort of public cloud environment, or through a set of APIs to developers or to DevOps teams or whoever it is who actually wants to exploit that infrastructure. If you think about, again, another show of hands in the room, who's used AWS, who's bought instances on AWS? So this diagram I first saw about six, seven years ago at an AWS meet-up explaining how AWS hangs together. Underneath behind the scenes, they've obviously got some networking, they've got a lot of cheap commodity compute, they've got a load of storage, they stick a hypervisor on top of it, Amazon put a modified version of Zen on top of it, some sort of orchestration layer, and this is what Amazon went and did first before anybody else however many years ago it was. They wrote an orchestration layer, a layer that would take control of the hypervisor, take control of the network storage and compute and present that out in a self-service model at the front end. Really important that that has an API because this needs to be exploited in lots of different environments, and Amazon went and put an e-commerce platform on top of it, they already had an e-commerce platform selling books and CDs and all those sort of things and they built Amazon Web Services EC2 on top of that. What we can do with CloudStack is exploit the fact that organisations have already got those three first components. Most organisations in their data centre have got some network storage and compute. We can then take a choice of hypervisor. One of the key things about CloudStack as an orchestration layer is that it releases the tie-in to any particular hypervisor. We support KVM, VMWare, Zen, we're about to start supporting Hyper-V. That opens up situations where we can put workloads onto different hypervisors depending on the use case, we can move workloads around between those hypervisors. CloudStack then pulls all of that together. It then exposes a restful API. One of the key things with CloudStack is our API looks very similar, if not identical to the AWS EC2 API and the S3 API. That means if you've got tooling on top in terms of whatever it is, developer tooling, you're doing some platform as a service, whatever it is you've got on top, a CloudStack Cloud looks like Amazon web services to the rest of the world. OK, if you're a public cloud provider, you're using CloudStack, you may stick an e-commerce platform on top to let people come and buy instances because you're trying to compete with Amazon and do that sort of thing. Obviously you may have billing, management monitoring tools, et cetera, sat on top. And then, depending on the use case, whatever it is you're trying to do with that underlying infrastructure. Now, in the world of cloud that we're intimately involved in, that top layer is where all the exciting stuff's happening, right? Infrastructure's a little bit dull. But ultimately, to do any of those things at the top, you've got to somehow get down to your physical infrastructure and to be able to control and easily orchestrate that infrastructure. And that's what CloudStack does for us. In terms of the landscape around infrastructure as a service, there's lots of people writing lots of papers about which of these projects will survive and which of these vendors will survive. But I basically pigeonhole infrastructure as a service platforms or products, if you like, into three different categories. VMware, I've got a technological vCloud director, system centre from Microsoft is a similar sort of thing, allowing a concept of self-service to access that infrastructure. There's a whole bunch of guys doing what I call end-to-end solutions to Beacow on Appflexion. And these were guys who sprung up about six, seven years ago, aimed predominantly at service providers who wanted to do some sort of cloud-based offering. They wanted to do an Amazon-style offering. And these are sort of out-of-the-box solutions that will do the whole credit card piece, the customer portal piece, aimed firmly at the service provider market. What's also then happened at the same time, we've got a number of open-source communities springing up, of which obviously I'm involving one of those. CloudStack, OpenStack, OpenNebula and Eucalyptus are probably the four biggest projects in this space. And in terms of scale, obviously I've put CloudStack at the top, but it's not, OpenStack is the biggest project out there at the moment, it's got by far the biggest momentum. We come in second in terms of contributors, in terms of committers, in terms of commits, okay, and OpenNebula and Eucalyptus follow a little way behind. In terms of the future of the IS layer, I very much see that the vendor-centric and the end-to-end guys will start to see them sort of pull back and wither, okay? VCloud Director is a great technology, but it's there to sell VMware's hypervisor, that's what it does, it's a tool which sits on top of ESX specifically for that purpose. And increasingly people are telling us, our customers are telling us, we don't want that locking, we want the flexibility around hypervisor choice, we don't want to be buying something just because we've got a particular hypervisor in the building. And we're starting to see now a lot of the big virtualization projects getting involved in the open infrastructure as a service project. These guys in the middle, I think will continue to do their sort of value add thing aimed specifically at service providers, but are now starting to look at the open communities to do the heavy lift end of cloud orchestration. Cos if you think about it with infrastructure as a service, you want to support multiple hypervisors, you want to support whatever the latest version of NetApps OS comes along, you want to support whatever networking devices come along, you need people to easily be able to contribute into that code, okay? So it needs to be more than anything else really, an open community where vendors, individuals, third parties can come along and contribute. And that's why I see a heavy shift in the IS space towards the open source communities on the right-hand side. In terms of the background of CloudStack itself, today it's an open source IS platform available under the Apache 2.0 licence. Our community is vibrant and growing. We've got contributors in the hundreds, committers, I think we have 80 committers, Jeff's a committer, from lots of different organisations. A lot of the big storage vendors, a lot of third parties like us, a lot of service providers, and a number of other players I'll talk about in a second. The background of CloudStack is that initially it was a bay area startup called cloud.com, which is probably the best bought domain name ever, which is sat parked now. It's just sat doing nothing at that domain name. Citrix bought cloud.com in 2011 for $200 million. And then a little while later, donated everything out to the Apache Foundation. $200 million acquisition and they just give it away to an open source foundation, which I thought was great, but I have trouble explaining that to my mum. She doesn't quite understand the business logic in that. Okay, why did they do that? What it was all about was Citrix predominantly are a desktop company. They saw the future in orchestration and cloud delivery into the desktop. They acknowledged that they needed a platform on which to do it, but weren't really interested in maintaining that infrastructure as a service layer themselves. So they bought cloud.com, gave it to the Apache Foundation, hoping to develop that vibrant open source community, which is exactly what's happening. We went into ASF incubation and then graduated in March of this year to a top level Apache project. One of the key things is because of that history, taking a commercial enterprise grade product and bringing it into an open source community is exactly that. It's a product. I see it as a project we work on, but we sometimes forget that this is a product. We can lift out of the box, go and install and build infrastructures and service clouds very, very easily. It is not a framework of projects, of loosely coupled projects. It's a piece of software that we work on. OK. I don't normally do logo slides, but in the theme of CloudStack being the cloud's best kept secret, these are people using Apache CloudStack. What I'm just trying to get over here is hopefully everybody in the room will recognise at least one of these logos. This is a technology which is in production use in some of the world's largest organisations. Again, most people in the room haven't had an experience with it and only about half of you have actually heard of it. We're talking a lot of the big telecoms providers doing public cloud, Zynga, that incredibly successful until a few months ago, Games Company, who have one of the world's largest private clouds, Sun Guard, people like that. Moving on, these are more recent users, some reasonably big names in there, and these are all people who are running significant production clouds on Apache CloudStack. Now, some of those are public cloud offerings. Some of those are automating their DevTest environment. They're there to support continuous integration. Whatever it is, they're reasonably big users of this technology. We did a survey last year of users, and we also got a bunch of really exciting names who didn't want to actually share their use with Apache CloudStack at this point for political, commercial reasons or security reasons, but you're going to see over the next probably six, 12 months some significant organisations saying that they're moving to or adopting Apache CloudStack as their IS orchestration technology. OK, so what can we use it for? Three stovepipes, really. Public cloud, so mainly service providers, managed service providers, traditional internet service providers who want to do a self-service, buying virtual resources, buying networking as a service through a public-facing user interface. The private cloud I'm going to drill down to in a bit more detail, which is more people wanting to do internal automation than obviously a combination of those we have, the hybrid model. Service providers' public cloud's pretty obvious DevOps. So, hands up, who's involved in a DevOps team or has a DevOps culture in their organisation or, yeah, a few of you? Bringing together development and operations, it's all about automation. It's all about getting those releases out there as quickly as you can. Now, CloudStack isn't at the sexy end of that. There's a lot more exciting technologies that we can put on top to make our lives as developers much easier, but ultimately they all require resources, they all require infrastructure. So unless you can automate down there, it makes it a bit harder up there. And if you want to do any of this at massive scale and you want to very, very quickly develop assigned compute resources, you need to be automating that infrastructure underneath. One of the use cases we're seeing more recently, certainly over the last six months, is... This is my term, AWS Insourcing. So this is like the model for Zynga games. So Zynga built their business on AWS like a lot of gaming startups do. Seen the logical thing, they can put their credit card in when they're a startup mode and they only paid for compute resources and storage when they actually needed it. Fantastic, perfect for a startup. Then whichever of their games it was, Mafia Wars or whatever it was, went absolutely massive and their bill with Amazon went up to some crazy amount every month. And then they looked back after a few months and went, hold on, yeah, this elasticity of cloud is absolutely fantastic and we're getting these, still getting these peaks and these troughs, but our known usage is there every month. We know we've got whatever it is, however they measure, so many users. We know we need a certain amount of compute resources. So this is the idea of actually starting to take some of those workloads back out of a public cloud, a commodity cloud, bring them back into your own data center and running them through an orchestrated internal private cloud model, okay? CloudStack fits that perfectly because CloudStack has the fidelity with the Amazon API. So somebody like Zynga who's done all of that work on top of AWS or some of the organizations we're working with here in the UK, they put a lot of work into making their app sell scale on top of Amazon web services. They can continue to do that using their own infrastructure. And increasingly, still a relatively small part of it, we're starting to see, I hate this term enterprises, but traditional IT organizations wanting to exploit infrastructure as a service to speed up timer deployment and that sort of thing. Okay, terms of what CloudStack does, some key points, broad hypervisor support in terms of the hypervisors we can manage, scalable architecture. I'll talk through the architecture in a second. The largest single cloud built on CloudStack is 35,000 and counting, 36,000 and counting physical hosts. That is controlled from four CloudStack management servers, okay? And it's only four, so they've got two 8J pairs, okay? If they took away the 8J from a scalability viewpoint, two management servers would control all of those hosts. Scalable. We have the AWS API for fidelity. CloudStack also manages the 8J piece, so it sits on top of the hypervisor and manages the high availability aspect. We have a virtual networking model within CloudStack and this comes from the fact that it was initially designed as a multi-tenant thing for sort of public cloud. So network isolation between those tenants was a key part of that orchestration. So we have a whole virtual networking piece. We'll talk about that in a bit more detail in a second. We've got a simple web UI. We've got a command line. We've got a REST-based API. Terms of the architecture, terms of what it does. User interface at the top with the API. We manage things like backup, load balancing, 8J. We manage resources in terms of network storage and compute. We do a piece around managing image libraries of machine templates. If any of you are involved with OpenStack, that's glance, but we have that integral to our product. We then manage obviously the hypervisor underneath and then have various integration points out at the side. How do we deploy CloudStack? CloudStack is a management server, okay? So we build that management server normally just on a sentos box. Again, normally in an HA pair, hence the S there, okay? It sits on top of a MySQL database. And what CloudStack is actually doing is storing a load of automation commands to send to hypervisors and to network and storage and compute, okay? That's why it's so scalable, okay? CloudStack has a concept of secondary storage. This is storage where we put things like images, templates, backups. The less important stuff, the stuff we don't need the high-performance storage for, okay? And that lets us choose much cheaper storage for that side of things. The logical points of scale for CloudStack, we have a concept of a zone which is similar to an Amazon availability zone and that tends to equate to a physical data center for most people. It doesn't have to, but it normally does. So you may have a UK zone, a France zone and a US zone, okay? The next level of scale is a pod. And a pod tends to equate to a rack in a data center. Again, it doesn't have to, but that's the natural scale point. And a pod has hosts within it and also has some primary storage. Primary storage is what we use to run the virtual machines. So that's where we tend to have a higher performance storage of whatever performance level we need for the service at the front. And we tend to scale out. The logical scale point for CloudStack is normally on a pod basis. We've got a lot of customers who have now got a reference pod architecture, very simple to pre-configure that those can go into data centers and they can scale, scale, scale. Admins and users come in, see the management server, the management server then orchestrates all of the pieces behind. Okay, typical deployment. We have a management server sat at the front, the zones with the pod sat behind it, a HA pair of MySQL databases, some sort of load balancer at the front. Okay, CloudStack offers a networking as a service model. As I say, this is about the legacy of it coming from that multi-tenanted public cloud environment. And it actually offers two different models that we can implement at a zone level. So I can have a zone that is an advanced zone, networking model and a zone that is a basic zone. There's no limitation on the number of those zones I can have. Basic zones are there to replicate Amazon style services, the Amazon style of networking. So this is a very flat networking model. What it allows us to do is to be massively scalable because it's not really doing much down at layer two and layer three. And it allows us to create a very Amazon-like cloud environment. An advanced zone can use either VLAN or SDN isolation using something like NICERA, Midokira for example. We're hoping to do some work with open daylight further down the line. And that then uses its own virtual router that each customer or each tenant gets given or each department if it's in a private cloud. And that virtual router can then be managed through the user interface or through the command line or through the API. And that allows us to take lots of services, load balancing, firewall, et cetera, et cetera, in a cloud interface and control those services. Okay, this is Jeff and that's me at the back. Jeff's going to do us a demo, talk us through the user interface. As I said, most of the time a cloud stack, people aren't using the UI, they're using the API, but looking at the API isn't particularly sexy. So Jeff's going to talk us through provisioning some virtual resources, controlling them and looking at the networking bit of cloud stack. Have you got on, Mark? Do you want this? Just get the screen up. Okay, thank you, Jals. So what I'm going to do, Jals, is log in to our demo rig that we've actually got running on this laptop here. So give you an idea of the scale. We've talked about 60,000 hosts. We've got it running on a simple laptop in virtual box. We actually built this cloud on Monday morning when we got here for the conference for demo purposes. So it can actually be deployed quite easily, quite simply, in a small environment or very large scale. When we realised that the Wi-Fi here was... It was a bit flaky, yes. So this is the initial login as a user, and just to highlight that we've got lots of language support currently available, more languages coming online all the time. Altues, obviously English, and that you love live demos. Can I ask the live demo? I'll tell you what, while Jeff is dealing with the demo gods, let's take some questions early if anybody's got any questions. Cos I want everybody to see the live demo, and I don't want you to have to watch him fix it for five minutes. Question over there, Pino. Maybe, maybe, what I do see... So the question was, will cloud stack adopt neutron? Will cloud stack and open stack as two projects start to work more closely? Yes, almost certainly. I mean, we've got Swift support, for example. Our architecture, because of our history up to this point, has been, let me say this, reasonably monolithic. We're a project, that's one of our advantages, with this sort of product that can be installed, but we are actually moving to a more modular architecture. So all I can see going forward is areas of the open stack project, areas of the cloud stack project starting to focus on different areas and then start to exploit each other's technology. So maybe not, but the overriding thing, almost certainly, there's going to be some more collaboration there, I'm sure. Question at the back. How is it today? It's got a bit of a cold like me. The bare metal driver. So yes, we support bare metal, which uses Pixie. It's in use in some very significant clouds. The version that's in our master branch needs a little bit of work, but it's there, it's supported. So instead of hypervisor, we can deploy bare metal servers. We've also got some very interesting and very significant hardware vendors who are doing some work in the community as well around some of their own automation stacks and using cloud stack to tie into that. How you doing? Blame it on the Wi-Fi. Go on. Somebody ask another question just while Jeff fixes it. We're in. Good. All right, perfect timing. Hold on, off you go. Didn't like moving from downstairs. You got comfy down there. OK, so I've logged in as a user. This is the simple user UI that you see when you come in. It's like a dashboard view. It tells me what's going on with my environment on this cloud. As we can see here, I've got a total of six VMs to running for or stopped. I've also got an alerts page giving me information about what alerts have been going on, the fact that someone's created a VM, created firewall rules, et cetera, and I can drill into those alerts and see the history of everything that's happened in my account. So a lot of this is about actually creating VMs. Gels, you get feedback. A lot is about creating VMs. So let's start with a quick demo of how to actually create a VM using the UI. So I've actually logged into the system, so I've basically logged into the first region and Cloud Stack like AWS has a concept of regions. I've now got an ability to choose the zone within that region and a region can contain multiple zones. So here's a Linux one that we created for this event. I then get a choice of, do I create this VM from a template or an ISO? So unlike, say, Amazon, where you can only create from templates, we can actually boot an image, sorry, boot a VM from an ISO and you can then install the VM yourselves how you like it to be installed, not relying on somebody else. The more common option now is to actually use pre-configured templates to actually launch the VM much more quickly. So a template is basically a pre-installed software, Windows, CentOS, whatever the hypervisor can support, Cloud Stack can support. So I'm going to choose this CentOS template here and this will basically give me the root partition fully installed to the point where whoever built the template decided we need to be. Obviously once you've got the VM running, we can then add additional software onto that base OS. You'll see from this here, we've got some examples of VMware's end server. If we had KVM available, we'd have KVM listed and any software that a hypervisor can work with, so can we. Now, the next question I get asked is about the compute offering. So the compute offering does more than just compute. Yes, it does, defines that I'm going to get x number of CPUs, x number of memory, but it also controls the storage architecture. So the admins can set these up and they can say, well, this is a shared storage offering using high-performance storage or using local storage. We can say that the storage is going to be got certain IOPS, so we can now with the right underlying architecture give you guaranteed IOPS, 100, 100, 2000, burstable and at all in a different range. So we can control much more than just CPU and memory. We can also say in these offerings that it's a HA offering. So this VM is highly available. If the host that the VM is running on goes down, CloudStack will automatically restart that VM on a different host. We can also control the fact that the network rate can be prottled on this offering. So the admins may give you, say, a one gig network, a 200 meg network, the list goes on. So there's a lot of things going on under the hood that these offerings control and the description what the admins put in hope it helps explain what each offering offers. In a public cloud space, they would obviously have different prices associated with them so you choose an offering that meets your requirements for computing resource and cost. So as we're running on a small laptop, I'll go for the smallest option. I now get the option of offering a data disk. So the template's given me my root volume, C drive. I can now also add a data disk and I can choose again from predefined offerings of set sizes. Or if I want, I can even go for I'll decide how big I want the offering to be using a slider concept. So I, as a user, have got lots of control. If I choose not to create the disk offering here, not a problem later on, I can add a disk volume anytime. I can even add a volume, remove it, change it, add it to a different VM, take it back again, move it around VMs. So I can very easily move data around between VMs. I can even upload and download volumes up from the cloud and to the cloud. Now affinity groups are a new in the latest release feature. What they give the end users is the ability to control the grouping of their VMs. So at the moment we've got anti-affinity groups, which means as a user you can say, I don't want any of my VMs on the same host. So the system will try to force spread around the VMs across all the different hosts. Once we get affinity rules in place in the next release, you can also say, well, actually, I prefer these VMs to all be on the same host because they're talking a lot to each other and I like having them together because if one of those VMs is broken, the whole workflow is broken anyway, so it doesn't matter if it's on the same host. So you get some options to control things. I'm not going to select any for now because it's anti-affinity, I've only got one host, so it won't like it. Next we get to choose a network offering. So I'm going to drill into some of these networks a little bit later on. So I'm going to choose this bottom option, which is just a standard isolated network like Giao's explaining. It's got a virtual router. It's using VLANs for isolation and it gives me all those bells and whistles that I can control as a user. If I had multiple offerings here, if I wanted to, I could create this VM and map it to multiple networks so I could have three or four virtual interfaces. Later on, if I decide I want to add or remove those interfaces, I can do so. I can move VMs across different networks and move things around. So I'm not tying myself to these options I choose today. I do have flexibility later on. And then we need to give it a name. I think I've got no VM004 in there. Go. So that's the wizard bit filled in. What's happening in the background is it's taking a template from secondary storage, moving it to primary storage and spinning up the VM. Now this is on a laptop, so it's going to be pretty slow, we assume. If we had real hardware, it would be much quicker. Actually, that's finished. That VM's now running. That's how quickly we can create VMs on a laptop. So enterprise hardware, VMs can be coming online almost instantly. So when we've got options of autoscaling and bringing VMs on and off as we need them, very flexible, very high performance to actually create VMs. Now we've created that VM, but what can we do with it? So we drill into the VM, we've got a myriad of options across the top there. So we can do the simple things like stop and start. Straightforward, we can kill it off. We can take a snapshot. So an actual snapshot where grab a snapshot now, it grabs a memory. Show you the options. Give it a snapshot, give it a name. Say, yep, snapshot and memory. That's going to give me something I can actually go back to if I'm now going to make a config change, if it goes wrong, quickly revert to that snapshot and start again. So that's nice and useful. Now what can be a bit confusing is we've also got what they're calling snapshots of volumes, which I personally prefer to think of as volume backups. There's still label snapshots as of today, but it's let me set a schedule for snapshots. So I can then snapshot that volume every day, every hour, every week. And these snapshot backups are going to get copied back to that secondary storage that was mentioned. So they're not staying on the same storage as a running VM. So they're nice and secure, nice and safe. And if this VM has a problem in the future, something goes wrong, I can use that snapshot to restore the VM back to a certain point in time. I can even use that snapshot that's in zone one to recreate a VM in zone two. So I can actually use it to move VMs around different zones as long as we've got the right infrastructure underneath. So massive amount of flexibility that I can do. And again, this is me as a user creating all this architecture in configuration. So other options I've got here, I can attach an ISO. So having booted my initial VM, I can attach now an ISO to that VM to install that additional software. I can also reset the user password. So we've got a facility built in that with a certain script included in a template, which a service provider will always build in their templates, windows, all Linux based. If I forget my boot admin password on my windows admin password, go on to interface, reset password, reboot the VM, it will randomise a password, tell me what the new password is and I can get back into my VM. So no need to log support calls to the admins. As the user can reset things. I've also can reset my keys. So I can use SSH keys to actually log on to the VM. I can generate and reset those as well. Now, one of the really cool features, now this is a bit slow on the laptop. It'll take 20 seconds to load up. But we've actually got a console proxy. So this is a HTTPS secure tunnel proxy down to the console session on the VM. Works on all the hypervisors. So it means that I can interact with that VM at any time. This is why we can boot a VM from an ISO. We get direct access to that VM regardless of the actual state of the network on that VM. So this has come online now. So I've got a secure tunnel through to this VM, which is going to work. You love live demos. Well, you can see it's there. This is a screenshot. Yeah. Come on. Right. The curse of the live demo. What I was, there we go. Am I just too impatient? It was still loading up. Just to demonstrate, we've got this VM and I can ping my default interface there. Should be 10.1.1.1, if I'm rightly. So just to demonstrate that I can actually kill off networking and still interact with this VM. Go on, that one won't work, is it? What type in line? Service, thank you. You need to develop dyslexia right now. This is rubbish keyboard in this laptop. So I've just killed off networking. But I'm still on the VM. I can still configure it, still control it. Because we're not relying on the network stack on that VM. We're actually using VNC to proxy onto the hypervisor and then get to the VM. So we can go and reconfigure VMs, safely knowledge that if we screw things up, not a problem, we can still get in there and fix it. So really powerful feature. Great way to get on to those VMs once we've got them created. You had to show you various things like what virtual interfaces are on there, give some stats, et cetera. Now this VM at the moment has got a single IP on that VM on one interface. We can actually now map multiple IPs to that single interface. Great if you've got a web server and you want to add multiple SSL certificates to link to the IP address, et cetera. Now when I created that VM, I linked it to a network and this is where some of the real powerful features of CloudStack come to the front. So I'm going to drill down into the network that that VM is attached to. And it's at the actual, this network's now got three public IPs. Those IPs are obviously 10, 10 aren't real public IPs. It's a test environment. They would be internet facing public IPs. So I initially had the one IP and that gives me a lot of the functionality. So I enable the VPN functionality as a user. It's off by default. So I've now got an IPsec VPN, multiple users. I can create the username passwords, give my dev users direct access to that network and all the VMs that are on that network. So then I have to mess about with going through firewalls, got a nice VPN straight in. And this is all out of the box, all things that I can do. Now drilling into that firewall, I've now got various configuration options. So this is the virtual router that we mentioned. I can go in and configure firewall rules. Now there should be some pre-configured. I'm on the right one. I am. Here we go, thank you. So there's some pre-configured here by the VPN configuration, but I've also manually added, say, a port 80 firewall rule to allow poor 80 traffic through the VPN, so through the actual firewall. I've also labeled a range of ports, two to two one to two to two three. So why have I done that? So step one, enable the firewall rules. Step two, map them to a VM. So what I've done here is I've mapped those IPs, those different ports, so two to two one, I've mapped to port 22 on VM number one and 2222 VM number two et cetera. So I've now got SSH access to three VMs on that network without even bothering about VPNs. I just launched my favorite SSH client, direct SSH onto those VMs and managed them remotely. Now we saw poor 80 was being opened on that firewall. That's not in that list because I've actually set up a load balancing policy for port 80. So here I've basically said we've got port 80, I've got a couple of VMs, let's load balance port 80 traffic across those two VMs. Now we added a new VM during this demo, so let's add that to that existing architecture. So I've now got pre VMs and that load balancing policy. And I've got some quite advanced options on that load balancing, stickiness, health checking to see what's going on. Can all sorts of things you expect from normal load balancing architecture? And this is currently running from the virtual router. However, if I could say I prefer F5 load balancers or CitrusNet scalers, we could use those as well. So those devices can be orchestrated by CloudStack fully integrated, and as a user, when I'm configuring these load balancing rules, I get the features that those advanced devices can also give me, but I'm still configuring them. I don't have to rely on admins to go through and configure advanced load balancing or port forwarding rules or any of these wonderful features. I, as a user, am doing this and CloudStack is orchestrating all of it. We've also got a concept of net scaling, that's like autoscaling. Now autoscaling today is a net scaler feature, so you do need the net scaler integration, but the community are working on an open source, one that can be working with a virtual router. Use case for net autoscaling, you've got a few websites, web servers are running, you have an advert go live on a TV or global marketing campaign, and your traffic's on these bikes. So what you could do is you could spin a lot of VMs up just in case you're going to get busy, pay for all those VMs and then hope the traffic gets busy. Or using autoscaling, you could configure it to monitor the bandwidth throughput through the autoscaling device or the actual CPU memory load on those VMs, and if they exceed certain parameters, the system will create new VMs based on the same template, add them to the auto load balancing policies, and you've now got four, five, six web servers handling that traffic. When the load decreases, the system will detect that and then destroy those extra VMs so you're only paying for what you need when you need it. So there's some very powerful features that we can do here. Now, one of the last really cool networking architecture errors. Errors, wonderful. I think we've had a curse of the... That's all right. We'll go through our backup plan. Oh, my joke now. Sorry, why is that the wrong way around? Let me just restart that presentation so we can see it properly. Go on to date. Is there? Thank you. Where's the doodar? Thank you. So what I was going to show you was the VPC functionality, but the laptop's playing up. So VPC is basically tiered networking. So a really powerful feature. As a user, I can create multiple networks. Each network has its own VLAN, its own IP schema, and they're all connected together by the virtual router. I can then control what goes on between those different layers. It's not working at all. I think it is the recording software that makes it look a bit slower than laggy. Looks like it's stopped on my screen there. Resume slideshow. Thank you. So we've got these multiple tiers. So each tier gets multiple VMs, typical use base, web tier, app tier, database tier. You want to separate the traffic on those VMs. So we place the VMs on each tier and then that virtual router interconnects all those tiers and lets us control traffic using ACLs between each tier. So for example, we can load balance to web tier to do public internet. We can then load balance traffic between the web tier and the app tier, allowing only certain ports through. We can then also load balance traffic between the app tier and the database tier. And those bottom two tiers, we can keep completely locked down away from the internet only exposing the web tier. So we've got the public gateway that gives us a connectivity to the internet allowing us to share data on those networks. Now, VPCs also give us a cool site-to-site VPN functionality. So a standard virtual router lets you do user VPN, but a VPC also lets you have that permanent site-to-site connection to a VPN endpoint in your offices. You've got that permanent connection always in place. Another cool feature is the private gateway. This is something the admins can enable that gives you basic second leg out of the VPC into the data center. And it can be used for various things, such as connecting to other equipment in the data center, whether it's physical equipment or another router that goes to another DC. It might be connecting to an MPLS network that your office is on or you've got other equipment in another data center on. You might also have another VPC architecture, another VPC cloud somewhere in different DC. And again, we can do direct connections between the two VPCs to interconnect all this traffic. So, very powerful features, lots of clever things that we can do with those. Right. That's it for the demo. Thank you guys. I'll hand over to Giles. Really good demo, Geoff. And the key thing to remember there, we're looking at a user interface. And Geoff, you're talking about the users, but imagine that the power of that with an API that you can roll up into a script and say, OK, give me a test environment. Give me a test environment with this networking with these servers configured like this. Run some config management afterwards with something like Puppet and Chef to deploy some stuff onto those servers and a low balancing environment because I want to test how my apps are going to handle being in that low balancing environment. All of that doable through one single API, instead of having to go and talk to a gazillion APIs to do those sort of things traditionally. All right. That's the end of our slides. We've now got a picture of Homer Simpson looking. Hopefully. I googled silly questions, and that's what I got. So any questions, guys? We've got about five minutes. So the question was about snapshotting as a backup mechanism snapshotting and how it influences performance with primary storage. So there was two types of snapshots. The initial snapshot is a snapshot like you'd expect to have in a normal hypervisor where the image is an image taken of the existing VM. And then, obviously, we get the chain building up with those snapshots. So they, snapshots, stay on primary storage so we can very quickly roll back to those different snapshots. The second snapshot, the volume snapshot, which is a backup of the volumes, they get copied back to secondary storage and don't remain on primary storage. It depends on the hypervisor. So Cloud Stack is orchestrating the hypervisor. So in the case of volume snapshot, it will actually use the snapshot technology of VMware, of ZenServe, of KVM2, clone the disk image, and then it copes it off to secondary storage. And currently for the live snapshots, it's VMware and ZenServe only, and it uses the underlying technology of those hypervisors. Great. Next question. To what extent are surveys are supported? So the question is around the e-commerce layer. Maybe my slides were a bit misleading. Cloud Stack doesn't have an e-commerce layer. Cloud Stack, you would put an e-commerce layer on top of Cloud Stack. So question a little bit out of scope. And there's a number of commercial vendors doing that. Citrix themselves have got an offering around that. Or service providers are building their own on top of it. So in the case of the virtual router, the underlying technology is a Debian Weezy VM. So it's a special sort of system VM that's been built by the community, stripped down to the bare minimum number of packages installed to keep it secure as possible, lots of security features, and it's using things like HA proxy for low balancing. So all the open source standard Linux resources. But we can replace that with a GiniPress RX firewall for firewall functionality. F5 low balancers, Citrix net scalers. We can leverage external physical devices as well and combine how the network is configured. But by default, the virtual router is a Debian Weezy VM. Is Weezy simple. Is it for the VM? Yep. That same VM. That same virtual router provides all that functionality. And actually sort of leading on to that, one of the interesting things is seeing some hardware vendors at the moment starting to come in and write adapters into Cloud Stack to allow Cloud Stack to exploit from the specific functionality they have. So we expect to see not just the virtual router going forward. So the question was the router is deployed on each host. Each network and advanced networking architecture gets a virtual router. So it will be on any host in the cloud and the VMs belonging to that network and router will be on any host and they're connected by a VLAN that gives them the isolation. So each network on each account will get one virtual router. You can also configure network offerings that use physical routers and therefore be moved in need for the virtual router entirely. So there's lots of different ways of doing things. So, over there. Was your question about Open Stack or Cloud Stack? Very Cloud Stack. Exactly! We have customers who say that. So what config management systems are underlying this? Cloud Stack is vanilla. So Cloud Stack is, in short, apart from the networking piece, which is quite complicated, it's orchestrating hypervisors, like Jeff said. So, you know, it's really just automating those existing hypervisor technologies. In terms of then, on the back of deploying an instance, yeah, people are using Puppet, people are using Chef. Paul's doing a lot of work with the new one, Ansible at the moment because, yeah, we all know deploying a virtual machine image is only going to get you so far. You've then got to get stuff onto it. In terms of building the environment, different people are using different things. In our organisation, we do a lot of work with Puppets. We know other people are using Chef. Well, Gels, if I may, a method we use a lot of the time is that installing Cloud Stack is as difficult as going, you're going to install Cloud Stack management, is that simple? To then configure it, we use the tool that Cloud Stack community built called Cloud Monkey. And it's a basic CLI for the API that lets us compile lots of scripts that then do all the automation of the configuration. So, like, on Monday, when we built this cloud, we had some pre-configured scripts, we installed the Rando scripts to suit the environment we had available, and that got Cloud Stack coming in very quickly. So that gives us that build, the initial sort of configuration, and then we get on top of that, start to add users and accounts, et cetera. But Cloud Monkey is a really powerful tool you can use with Cloud Stack. I think the question is probably coming from the sort of open stack side where you have multiple different modules and projects that you've got to tie in together. Cloud Stack's not like that. Cloud Stack is an installable one thing. It's a product. It's a product so you don't have to have a configuration management that's going to tie up multiple different servers and multiple different hosts doing all different things. So it's almost not required. All we have to do is deploy some hypervisors and then Cloud Stack will go and find them. Question down here? Do I have some control over the different stages of the provisioning process? Can I hook somewhere inside there, say after creating the secondary storage or after setting up a new VM or whatever? Because I could... In a hook like this for the configuration system? Yeah, you can. We would rather MQ behind the scenes. There's people who are doing exactly that. We've got storage vendors who are doing that sort of work. Any more questions? We'll be back. When you say, so the question was, we've got this laptop config. We've done some work on it. We want to upload it. Just clarify what you mean. So one of the good things about Cloud Stack is we're aiming as a community to ensure that we don't build a cloud lock-in to this type of architecture. So Jals mentioned we've got fidelity with the AWS APIs, S3, EC2, et cetera. So we've got that fidelity because we can transfer workloads between different clouds. So those VMs I've built as a demo, I can download those VMs, go to another cloud, upload them and start to use them. So I can transfer volumes, VMs and get data in and out and move between clouds quite easily. And actually a slight tangent to your question, but in terms of the way Cloud Stack is put together, if we switch the management server off, the whole infrastructure carries on working. So all the management, all Cloud Stack is doing is giving instructions to hypervisors and some virtual networking components at the time of creation or destruction or starting or stopping. Apart from that, effectively, we've got a lot of virtual machines running in Zenserv or KVM or what have you. So, in terms of getting data in and out, it's a lot of virtual machines. Another question. I'm looking this way. Yes. So the question was that when we create a snapshot of a VM, that's obviously going to snapshot the volume, the configuration of the VM itself, or what if the network configuration has changed. To be honest, I'm not too sure. If you have moved the VM around, because any changes will have been orchestrated by Cloud Stack, so it will know that that VM is now sat on a different network. Obviously, the VM itself, when it comes online, will get given an address by the virtual router that also acts as a DHCP server, DNS server, amongst other things. So Cloud Stack tells the VM when it starts, your IP is going to be 1, 2, 3, 4 via the virtual router. So, even if the VM has been moved to a different network, it will still come online on that network, because it gets told that it's on that network by Cloud Stack. The benefit of having it all orchestrated by one device, one system, is that you have complete control and everything knows about everything else. For the management server itself. So, the management server can be installed on Rails, Centos type or Ubuntu as well. So, it's supported on Rails, Centos and Ubuntu. I don't believe anything else. So, we generally build it on Centos or Rails. Most of the problems are beyond those. Rails, if the end user wants support from Rails or Centos, if they're happy, we just open source. And there's no difference if you choose Ubuntu or Rails or Centos, it performs just the same. So, you can choose either. It's up to you what your preferred OS is. Another one up front. I understand that Cloud Stack is an attachee project. Correct. Would there be some specific integration of one of the other attachee projects, especially like the HTTP server in the future? Yeah, that's a really good question. So, as an attachee project, are we looking at other attachee projects? Yes, it's a natural place for us to go. To be frank, we only came out of incubation this year. We've done a lot of work in getting our community up and running and going through the governance model. And at the moment, we're sort of focused on just making Cloud Stack do exactly what the world wants. But maybe not as much in terms of integration down, but I think certainly up. There's a lot of projects working on tooling, multi-cloud, j-cloud, that sort of stuff, above Cloud Stack. And we've got conversations going on all over the place. But I don't know if anybody's ever been involved in an attachee project. It's sometimes a bit difficult to have strategic conversations between projects because the projects are reasonably isolated. Live migration? Yes. So, a question is, do we need live migration? So, a user can't live migrate to VM because they have no knowledge of the underlying architecture. However, as an admin, you can go in, you can live migrate any VM on any of the hypervisory support, KVM, VMwares, then, et cetera. Click a button, the VM live migrates, the user will be completely unaware that that's happened. How about that, though? Yes. Yes, so it's a shared file system. We can also, now we've answered, but do you actually live migration of storage as well? So we can live migrate running VM and its storage between different storage devices. So lots of control, lots of flexibility. It depends on the VM. So, for storage, our sort of go-to storage will be NFS for the primary and secondary storage, but we can use iSCSI, fiber channel, HBAs, whatever the hypervisory supports basically. Can we do live migration of a live area of your network? Sorry, no. So one of the building blocks of CloudSat was the concept of a pod with a cluster and a cluster is a selection of hypervisors, normally about eight hosts, with their dedicated primary storage. So live migration works across those hosts within that cluster using that shared storage. With ENSA, we can now migrate storage and we can migrate between hosts. Now that's in one data centre. If you had low latency links between two data centres, you could in theory stretch a cluster across two data centres and therefore do live migration across there as well. But that's a theoretical possibility, it's not been tested. So the question was, does it provide an API so you can automate live migration? Yes, so CloudSat's an orchestration engine that has an API. The UI we demonstrated is like a sample UI that you can build to interact with the API, but the full power comes from using the API. So using Cloud Monkey, I mentioned earlier, with the API you can write quite complex scripts to do a lot of automation. The API, we've actually got a catch-up situation with the web user interface where everything goes through our API, our REST API first, and then it works. So we've actually got a super set of functionality in the API, but everything you see comes in through the APIs. To give you an idea, the API is very powerful and we at Shapely, when we actually build these larger architectures, we do it all using the API. We literally bring up the UI at the end just to make sure it's all working, but we use the API for the initial design, build, deployment, test. We get the whole deployment using the API, Cloud Monkey and other scripting technologies. We've run out of time. We'll hang around if anybody's got any more questions. There was a man meant to flash a five-minute thing at me. I don't know where he disappeared to, but thanks for five minutes. Thank you very much for coming, guys. We'll hang around if there are any more questions.