 Yeah? Okay. Hi. It's a big audience to talk to. Thanks for, thanks for coming. So I'm Andy. I'm one of the founders and the CTO at Coho and I'm gonna tell you a little bit about what we build and what we do and if you want more information you can come and talk to us at the booth and if you have questions you can try and get past everybody else to ask them. And so this will be a pretty fast discussion of stuff I think. So as a graduate student when I was doing my PhD I went to the University of Cambridge and I was one of the authors of Zen. I was one of the guys who wrote the Zen hypervisor. We did a startup on Zen and we did that for a few years and then I actually went back and was a prof for a little while. I was a prof at UBC in Vancouver so I actually live in Vancouver. And so a few years ago we decided that we had the appetite to do a startup again and that we'd seen some really interesting problems kind of fall out of the work that we did with Zen in particular around storage, right? That there are some really big challenges in terms of building enterprise storage systems and that weirdly with the work on Zen we saw this weird split where we were doing the startup to package and kind of compete with VMware and we were selling into enterprises that were buying a lot of like EMC and NetApp type storage. And on the other hand we were you know a bunch of us went and worked for places like Amazon and Rackspace and we were working with those environments around building you know large cloud-style storage off of commodity gear. And the two things were incredibly different, right? The the storage that was being sold into the enterprise was really expensive and was basically replaced every three or four years and the storage that was being built inside of an EC2 was incredibly scalable, incredibly versatile and staffed by a team of about 20 people wearing pagers that scrambled and drove into the office whenever it fell down which it did fairly frequently. And so you know part of what we wanted to do with Coho was to bring some of those ideas around commodity hardware, scale out storage and apply them in a more contained environment. And so that was sort of what we started with. We did about a year of development on that work and during the year that we worked on it this really, really kind of interesting thing happened. We went and presented sort of some of our early work to this all-flash company called Fusion IO, right? It was an early flash vendor and the guys at Fusion had taken these SSDs that we'd had for at that point about you know six or ten years and moved them on to a PCIe card, right? So it was kind of the same flash but they moved it on to PCIe. We have a lot of this today. In fact there's the NVME spec for really high-speed flash devices on PCIe and what we saw with the flash on PCIe was that it was really, really hard to saturate it. Really, really difficult to get the numbers that even Fusion was talking about getting off the card. And that kind of ended up defining a lot of what we did with storage. And so I can kind of illustrate this with a couple of graphs. So that's Vancouver. If you want a job and you like Vancouver this week, it's like this all the time, right? So come and talk to me and we have about fifty engineers here we're hiring. So Intel is this project called the DPDK. It is a software library for building scalable routers on top of Intel hardware. So it's a user space library for building really, really fast IO paths but primarily for network middle boxes. So people build switches and routers and proxies and to some degree like web servers on this stuff. And the DPDK guys had the summit last year and they were looking at the performance that they were faced as people building software paths for routing. And over the last twenty years this is what they see, right? The amount of time that a CPU has to process a packet has fallen from around seven thousand nanoseconds down to about six nanoseconds. And this is a really, really big problem on the networking side because you have less and less time to make a decision as to what to do with a packet. And in fact, right, the CPUs are not speeding up as fast as the IO path is getting faster at this point. And so a really, really interesting thing to think about is what does the storage version of this graph look like, right? If I superimpose over the same twenty year period what storage devices moving from disk to SSDs to PCIe and NVMe flash to increasingly NVDim, right? The flash is moving onto the DIM bus now. Form factors. What does that mean in terms of performance? And so if I take this plot and I plot a second data series that shows disks over the same time, right? That line is the bottom yellow line, right? This is what has happened to storage performance. And what this means is that if you are building a storage system and you're using things like RAID, like OS based drivers for the storage, like any of these techniques that we've used to build storage systems for 20 or 30 years, right, you earn a lot of trouble because increasingly the number of cycles that you have to process a storage request are very, very precious. And in fact, if you look at the way even flash storage has evolved over the past 10 years, the flash storage vendors, even some of the vendors in this room are built using architectures that are based on still sort of single controller, piles of disks in behind a single server. And we realize right away that this wouldn't work, right? In fact, to punctuate the point, what I found was with a single PCIe or NVMe flash device, I could saturate a 10 gig NIC, right? So one device, the device that I initially got from Fusion and then from Intel and then from Micron and then from Intel again, right? We could plug that into a server and that single PCIe device could saturate a 10 gig port. And so if I'm going to do what we've done in building storage systems for a really long time, which is to build a RAID group behind that, the second card, let alone the remaining six cards that I plug in, are a complete waste of money, right? Because they can't expose any extra performance. And so what that meant for us is we needed to sort of involve the network. We needed to hoist sort of the way that you compose the system off of the single host. And we had to build a distributed storage system. Now, the challenge with building a distributed storage system that has these kinds of performance properties is you can go out and change the client, right? You can go and change what's happening on all the client machines, but now you just have to go and change the world, right? You have to get windows to take on your stuff or at least VMware to take on your stuff and open stack to take on. It's a lot of work. So we elected to be really pragmatic. We decided to support NFS v3 as an initial target, right? There's a ton of NFS installed, right? NFS v4 is exactly the example of why you can't change the client, right? It still is barely deployed at large. And we implemented NFS v3 as a scale out storage target on top of these really fast flash devices. We included a backing plane of disk in order to be able to have good economics for capacity. And so the system that we ended up building kind of looks like this, right? We sell today a physical appliance, but it's a software company. We build software. We have a Cinder driver that presents this as volumes over NFS into open stack. And the smallest deployment that you get is a 2U box with two physical servers, four 10 gig ports, four CPU sockets, four NVMe flash devices, right? It's four, four and four, because each of those things is a vertical pillar of dedicated componentry inside the machine, right? The software manages each socket to present PCIe flash device over a dedicated neck and scales out. And so the reason that I show some switches at the top of this is NFS presents as a single IP address, right? It presents as a TCP endpoint. And TCP does not scale out particularly well across a whole bunch of endpoints, right? It's hard to get active, active use of links across a whole bunch of ports. And even in a single 2U deployment, I have four of those links. And so what we went and did in terms of being able to present that performance was we started looking at what we could do with SDN switching, right? We started looking at what the emerging SDN switches were capable of. And we ended up bundling a 10 gig Tor. We use a Rista right now, but it's an open flow facing switch as part of the product. And by bundling and converging the software implementation of storage with the network, we're able to take the TCP stack that runs on the server and push it out a little bit into the network. And so that IP address that is surfaced for NFS from each host actually resides a little bit into the switching. And so when new clients come in, I'm able to steer those connections across the entire storage substrate, right? I'm managing those things as if they're a single endpoint. So a useful way to think about this, and it's actually, you know, exactly the way that we think about it is if you're familiar with the container notion of a microservice, right, a shared nothing component that, you know, runs on one host. And as you get load and you want to scale it out, right, this is what we've done to NFS. It's effectively a microservice style NFS implementation, except unlike a lot of the microservice orchestration frameworks, things like Kubernetes, they own the whole world and they can use things like net filter rules to direct traffic on the client side. Since we don't own the clients, we have to work with the network to do that load balancing and scale. And so that's where we're able to take advantage of the SDN switch to scale that stuff out. But NFS in our environment is really just one example of an application. And so that's kind of what the structure looks like. And as you add nodes to the system, right, and this is a common demo that we have in the lab is, you know, customers will come in and want to see what it looks like to scale out. And so, you know, we'll start with a to you install for 10 gig ports, right, driving load into storage, 40 gigabytes of traffic behind a single IP address, you simply rack another node, you plug in the four wires, and the system has a controller, right, a central bit of logic in the sense of an open flow controller, not in the sense of a sort of single controller array that looks at what's happening, and it rebalances the connections and it rebalances the data. And that's it. And so, you know, another aspect of what's motivating this is flash prices are falling by about half around every 18 to 24 months. And so the motivation for building a scale up system is partially being able to expose the performance, but it's also partially being able to allow our customers to only by the flash they need, right, and grow that over time rather than committing up front to three or four years worth of flash, which is what they've had to do in the past with storage products. And so, that's kind of what happens. I can, I can show you a really simple example of this. Hopefully, let me see. Not that one. This one. So, I don't generally, it's really been fun to be at OpenStack, but this isn't really a customer event for us for the most part, right? None of you buy anything. Right? For me, this is a really great opportunity to talk to people in the community, right? We've been meeting with people around our Cinder driver support, and as a hiring opportunity, especially, right? There are lots of really great developers here. And so, if you'd like to come and talk about work with us, I'd be happy to do that. We do a lot of really cool stuff. If you do want to buy stuff, I'm happy to talk about that, but this is kind of where I'm coming from. So, if you have questions about this, come and talk to me. And what I'm going to show you is something that we don't usually go through with customer sort of pitches, but it kind of illustrates some of the cool stuff that's happening inside the product. And so, in a SDN OpenFlow application case, right? The way that Google or Microsoft, for example, have used software defined networking is they own largely homogenous network environments with big wide area networks, that span data centers around the world. Google and Microsoft have both publicly talked about how they use SDN because the internal aggregate network traffic is significantly higher than the sum total of all of their external network facing presence. They do two or three times as much internal traffic as they do outbound traffic. And so, there's a really, really big need to coordinate flows, especially on the more scarce wide area links between sites. And if you get away from, you know, BGP and the other routing protocol ways of doing that, and even some of the ECMP style attempts to do data center coordination, and if you reach in and very explicitly manage flows with a complete view of the system, you can do very effective things, right? And so OpenFlow has this notion of a single SDN controller that is a complete view of the system and is able to make correct global decisions on the system that is different from old protocols for networking like BGP and so on, where they had that notion of convergence, right? That everybody would kind of do the right thing and it would converge on an okay solution, right? OpenFlow takes a single global view and tries to come up with an optimal solution. And that's kind of what we do for storage, right? We have a central controller, and the controller is aware of all the physical resources. It knows about the network connections coming into storage. It knows about the data that those connections are accessing. It knows how much space is free on each of the disks in the system. It knows about failures. And that thing is what computer science would call a constraint solver, right? It's a constraint satisfaction problem on a whole bunch of dimensions to figure out how to place things appropriately in the cluster. And the extra constraint that you need to make is you need to change as little as possible as the system runs because there may be this other globally optimal solution that means you have to move all of the data in the world at once, which is not what you want to do with a production storage system. And so this is what this is visualizing. You know, in that 2U deployment, right? The sort of like smallest customer config that we offer, that 2U has four 10-gig ports, right? As I said, four servers or four CPUs and four NVMe devices. A column in this is kind of one of those, right? I've drawn a box to show each of those notes. And rather than starting at the bottom and doing RAID or doing some kind of like a razor code hash and spray, we explicitly place big chunks of data in the system and we explicitly manage that placement over time. We kind of view the storage system as a NUMA from an OS perspective. And so if I look inside here, this is a VMDK, right? This is an image file in a VMware environment. And there's a policy on how the data inside that is forward and placed, right? So in this case, I've striped it into eight stripes and I've divided each of those eight stripes into two replicas. And the system has a sort of forwarding notion of how this data is placed. And what that means is when I change the environment, whether that change is performance-based or failure-based or expansion-based, I can make a decision as to how to deal with it. And so for example, if I look inside this node, there are a bunch of chunks in here that are spread across nodes in the other failure domain of the system, right? We pairwise have CPUs on a shared power supply and so we never want to replicate across that. So we divide the system into failure domains. If I fail this node, right? All of the nodes that have backed up replicas here are capable of participating in the failure response. And so when you fail this, what you see is the controller thinks for a second and then it organizes and arranges background migrations of data to recover the constraint on replication, right? Similarly, if I come to this cluster and I add an additional node, the system realizes that there's become an imbalance in terms of the capabilities of the nodes and it places data and it migrates connections to expose the new capability. And so one of the things that we're able to really clearly demonstrate with the system is you can start with this 2U, that it's exposing 40 gigabits of NFS traffic behind weirdly a single IP address on 10 gig ports. You can plug in a second box and as the system rebalances, you see the offer load increase to 80 gigabits, right? So it's not just that you're adding capacity, you're adding performance to the system as it grows. And so this is kind of the crux of what we do. We've recently, yesterday, announced our third round of funding. We just raised additional $30 million. So we're here for a while longer. We announced an all flash version of this product that does 320,000 IOPS in 2U of space and importantly can be installed next to the existing system. So you can choose to purchase and expand performance or capacity, right? Independently, this is something that you can't do with other systems. And we've begun to do a bunch of prototyping work where we're actually absorbing new facilities alongside NFS into the platform in terms of additional protocols and actually additional services directly mapped onto the data because the core of this isn't so much a scalable NFS system. It's a scalable network clustered front end and a scalable IO backend for data, right? With arbitrary applications running in the middle. And so anyways, I think I'm just about out of time. Thanks for coming and listening. If you're interested in staying in Vancouver in this beautiful weather past the end of this week, we're just at the booth around the corner there. And I'm also happy to sell you some storage if you wanna do that too. Thanks.