 Okay. Hello. My name is John Griffith. I work at SolidFire. We do a clustered storage appliance. This is a source provider up in Canada. So, today we wanted to talk a little bit about iWeb and block storage using OpenStack and SolidFire and kind of give you a little background on their journey into OpenStack and kind of how things have gone with them and what they've been doing. So, iWeb is one of Canada's largest hosting providers. They've been delivering reliable hosting and co-location for over a decade now. And one of their most notable things is they're pretty much famous for their reliability and their customer service. They've been in NetCraft's top 10 for rock solid reliability almost every year. They offer guaranteed service level agreements and they have a state-of-the-art data center that's over 90,000 square feet in Montreal. And then they have additional new data centers as well with a dedicated server capacity of over 35,000 servers. So, it's a really large operation. And they recently made an expansion into cloud service offerings. So, that's where OpenStack came in. So, you know, the first step here was deciding to go ahead and go into cloud hosting. The keys here for them were to keep in mind they wanted to continue to provide the service and support that they were already known for in excelling their, you know, continuing the reliability, continuing to provide the SLAs to the customers, you know, everything on the same level and the same part with what they were doing already. In terms of requirements for building their cloud and what they were going to use, some of the key factors were block storage, having block storage that was multi-tenant aware and to move away from server-based storage platforms and provide reliability, scalability, and the ability to set up automation thanks to the APIs and things like that. So, there's some key ingredients that they were looking for. They went through a number of trials, tests, prototypes, things like that, different cloud platforms other than OpenStack, other storage offerings as well. Each one had specific challenges and issues. And those that actually provided real true SAN block storage support were pretty limited. When it came to OpenStack, you know, they discovered the ability to scale out horizontally and then most importantly, from our perspective, the block storage features of OpenStack. So, out of the other platforms that were being investigated, OpenStack offered significantly more advanced block storage service. The other considering factor was OpenStack is significantly ahead of the pack in terms of maturity, in terms of features and growth, and the continued fast pace of OpenStack development. So, overall, OpenStack appeared to offer the best community, showed the greatest promise and the brightest future as a use for their cloud platform. So, at that point, you know, you determine OpenStack meets the requirements, testing looks good, everything's going well, and the future seems to align with their needs. So, the next step was to determine what back-end storage device they wanted to use. So, that's where SolidFire came in, a little bit about SolidFire. We create a highly scalable clustered storage appliance. We do all SSDs. We do inline deduplication. One of the big things that we focus on is guaranteed quality of service. So, we allow you to specify IOP limits for each volume on a volume per volume basis. And you can also go back and change that dynamically. We were actually founded by Dave Wright, who used to be at Rackspace. When he was at Rackspace, he was actually trying to determine how to find a block storage solution for the cloud. And he couldn't find one, so he decided to go off and build one. And that's how we came to do it. The key factors, as far as IWED vision, the fact that we offer, it's already on. We offer non-RAID redundancy and self-healing, so we're clustered storage appliance. We have a very high cost-to-benefit ratio compared to our competitors out there. We have an API that's designed specifically for automation and to allow you to do things like OpenStack very easily. And it also gives you the ability to give multiple service levels and service-level offerings through QOS and such, all from one platform. So, other products where you may have to say, I'll get an SSD product for my high-performance customers. I'll get SATA for my lower performance and I'll get some, you know, whatever. So, we can actually go ahead and disperse all those workloads onto a single solid-fire cluster. And then also, of course, since we are a cluster device, we don't have a single point of failure, so we do replication and everything else internally. So, this isn't still all right. So, the thing that's really cool about IWED, if you look at it, you know, they came in and they did the shopping and everything, and they found OpenStack and went with OpenStack, worked with us, implemented our solution from solid-fire. Everything went really, really fast. But what was really interesting was, after they started implementing this and using this, they actually came back and started contributing back into OpenStack. So, they came across certain things that they wanted to see, certain things that they wanted to do, maybe some things missing, maybe some bugs, maybe a new feature or whatever it might be. And this is kind of like, in my opinion, a textbook's case of why Open Source and why OpenStack works. There were things that they wanted to do and customize, and they actually went ahead and did that not only for themselves, but they also sent it back upstream. So, they contributed those changes and those enhancements back to the community. So, now everybody has those. So, to me, that's a huge, huge testament of why Open Source works and why OpenStack works. In addition to that, it's not just the block storage project, Cinder. That's not the only place they're contributing. They're contributing all over OpenStack and all of the projects. They're doing the same thing. So, it's a pretty fantastic story and it's a real testament to the OpenStack model and what you can do. Yeah, so the iWeb cloud offering was basically based on SolidFire, because as you'll see, there's some specificities of the cloud that are based on this boot-from-volume and this central block device. I want to say something about OpenStack evolution. Basically, OpenStack is moving very quickly. I've been working with OpenStack for about two years and it's changing a lot. And there's a lot of different backends, different implementation for storage, for network, and the specificities that we have with SolidFire, I wanted to talk about that. It's something that needs to be addressed by the OpenStack community to basically hide all these different clouds that are going to be spawned across the world and hide them behind a unified API, which is currently not perfect, but it's something that's going to get better with time. Okay, so iWeb's cloud is 100% boot-from-volume, so basically there's no local storage. In all our compute nodes, there is absolutely no disk except the operating system, a small SSD drive, because all the volumes that are backing the VMs, they come from SolidFire. SolidFire is highly fault-tolerant, so the data is persistent in all the drives. That means that the VMs, they are highly available, meaning if we lose a compute node, we will simply reboot the VMs that were on this compute node. They will reboot with the disk as it was when the node crashed, because the disk again is on SolidFire. So that's something that we wanted to provide to our customers. Basically, it is between a cloud and a VPS, meaning it's a cloud, definitely, but the VMs are more persistent than a standard cloud where you can lose a VM and lose the data on it. So it provides our customers with a different way to address this high availability. Some people will not benefit from it. They will do just like they would on a standard cloud. Some people will rely more on the high availability. As John said, one of the important things in SolidFire is the quality of service. So in our case, what we did is we kind of implemented the disk performance inside of the flavor of the VM. So basically, instead of having only CPUs and RAM, you also choose a VM depending on the performance you want. Some people, they don't need a lot of performance on disks, so they'll pick a standard QS. Some people need more performance to run database or Cassandra, for example, and stuff like that. They will just pick a flavor that provides them with better disk performance. So that enables our customers to deploy stuff that would be hard to deploy, for example, on Amazon, where they would need to mount multiple EBS and do a raid on them or something like that. There were some challenges to a fully boot from volume cloud. One of the things is that, like I said at the beginning, currently the API doesn't hide, the OpenStack API doesn't hide all of these specificities. So for example, to boot from a volume, you need to first create a volume or clone a volume and then boot on it. So you cannot just issue Nova command. You have to first create a volume with Cinder and then boot on it with Nova. So that's not a problem when you're using the API, but stuff like Horizon, for example, Horizon, out of the box it doesn't address this correctly in Grizzly, at least. I think in Havana it's fixed. But basically, I think the standard OpenStack in Grizzly is still with local disks, so we need to address that and make that better. That's what we're trying to do with the contribution. Like I said at the second point, the functionalities of a boot from volume are not always on par with the locally backed VM basically. We notice that some of the functionalities are simply not working with a boot from volume, so that's something we have to fix, for example, the rebuild and resize. Again, some of these stuff may work in Havana. So the solution is to contribute, give back to the community, fix the problem we have because I know for sure that it's not the only boot from volume cloud, and I think it's a good solution. So I think we're going to see more and more of these different clouds. A lot of success we had, for example, the ability to support different workloads out of the box, that was good. Some of our clients were dissatisfied with their experience in the cloud because there would be not enough IOPS to run MongoDB or other database systems. In our cloud, this works perfectly. If not, they simply improve the IOPS on the VM. They resize the VM to a better flavor that has more IOPS and suddenly database is working flawlessly. Like I said before, the VMs are highly available, so the famous example of a puppy versus a cattle. In our case, it's somewhere in between, I guess. You can treat them like cattle if you want, but when you write something on a volume on solid fire, even if you crash a compute node, you'll be able to... The data is never lost. Also, solid fire is very scalable. The deduplication, for us, it's great. For example, if you have VMs with 50 gigs volumes, if you run 100 of these similar volumes, the block level deduplication does a great job, so you're not using much of the space. For us, it's very great. Also, the scaling of solid fire is very efficient. If you need more IOPS, you add solid fire nodes. Every node gives you 50,000 IOPS. So if the cloud grows, you grow the solid fire back in and you're able to support new customers. So that's about it. Any questions? Thank you.