 All right, let's get started. Hello, everyone, good afternoon. My name is Abdul-Humana Khamis. I'm a technical manager at DDN Storage. Should was with me, Simon, from University of Birmingham and Maria, but they couldn't make it to the event for other commitment. So what to expect in today's talk? So today, we're going to talk about stuff on how to benchmark at the post-tax storage. If you're going to go today and buy a storage solution for OpenStack, we're going to discuss a real use case that we actually benefited from. So we're going to talk about stuff, how to avoid seeing like gigabyte per second, megabyte per second, and getting into technical to stuff that doesn't mean anything for your OpenStack storage. We're going to see a later demo on the approach that we talk and see what is the lessons that we learned. So just to give you a bit of perspective in DDN Storage, we actually come from the high performance side. So we usually go in the high performance computing and we plug into our storage to a single application. So we benchmark all our storage to one application. So we just need to know how this application is reading and writing, and we customize the storage to that application. So the benchmark will look like something like this. You see a lot of numbers. You run a typical Beachmark tools like Iosone, DD, that kind of stuff. And you say, yeah, I got to try it this time. But the thing that going into a cloud, you have a couple of applications. It's not one single application anymore. So we couldn't go and just tune the storage for one single application and walk away and say, yes, Mr. Customer, your storage will perform 10 gigabyte per second, 20 gigabyte per second, whatever that is. Because that number doesn't actually mean anything for your application or your customer application. Assume that if you end up today with a number like saying it will perform like 10 million IOPS, that's different from MySQL database to in-house application. Each application has a different meaning. So in this approach, what we are trying to do today is how you can know that this is the best storage configuration that you get. How do you know if adding an SSD to your storage will benefit your customer workload? So this approach will help you to know each storage configuration you change, whether it will help your customer application or not. So to give you a bit of background, we did this Beachmark with the University of Birmingham. They have what they call the Bureau Cloud, which is like OpenStack Cloud for bioinformatics environment. So they have a couple of publications. Scientists are using this cloud to accelerate their business. So we had a couple of stuff that we want to test. They had already running an OpenStack Cloud connected to DDN Storage. And they've been in a lot of OpenStack conferences. They've been hearing a lot of stuff that may help their environment. So they wanted to test a couple of stuff. So one of the things that they would like to test, what if we added SSD to our storage? Whether that will help our application workload or not. So if we turn on SFX, which is a caching technology that we have in DDN, another question that they said, if we run the application on the parallel file system, on IBM spectrum scale, or if we run it in Cinder, is that best for our application or not? So another question. Another question they have, does it matter if we run the application in a Tingigee interconnect or into an InfiniBad interconnect? So they had a couple of questions on small changes that they can do in the cloud. Or actually, we don't know how we can capture those changes. For example, using in Cinder, if you use extension for or XFS, how do you know if your application going to benefit from that change or not? So what we are going to do today is we're gonna take one question of these and see how we tackle that question and we get an answer. So the question that we're going to take is, if you switch to a Q code to a glance image format, how that will affect your cloud? So we talk that question and we say, let's see if this is going to affect our application and let's see if it's going to affect the VM deploy time. So just to give you a perspective before going into the demo, this is we have the storage and then you have the fabric where your hypervisor is connected to that storage. And then you have a couple of virtual machines running inside those hypervisors and then later on the application, there is two applications that the customer is interested about. One called BOA and the second is Micro-Piece which is an application that bioinformaticians really care about. So for them, they want their performance to, they want to tune their storage for those two applications. So let's get into it. Like we ask the question that like, okay, we're gonna change a glance image format and we're gonna answer two questions. Is the VM deployment time will be affected? And the second one, how is the BOA or the Micro-Piece will see this changes? All right, so here I'm logging to the end result, like how we figured this out. We're gonna see later what is the workflow and how we got these results. So just to give you a perspective here, I'm reviewing here Kibana, which is just viewing the benchmark results that we did. You see in the left-hand side, there is like 54 hits and what it means is that we did 54 benchmarks, okay? So every hit you see here, it's a single benchmark that we did. In the left-hand side, this is like couple of the variables that we are interested in. Like in each file system, it could be different variables or in each application that you are concerned about, it could be different variables. While you are writing the application, you can dictate which variable you are interested about, okay? So here what I'm going to do is search for, like I'm going to see a search for the VM deploy time. First, let me show you each single result, how it does it look like. As I said, this is like a specific to our file system. This can be any file system, SAV, LVM. It doesn't need to be those variable. You dictate those variable. For example, every time we do the benchmark, we capture the file system configuration. So we would know what was the configuration when we did this benchmark in order to tune it later or to design the storage based on that configuration. Et cetera, so you can see like how many number of VMs we run the job on, et cetera, et cetera. So here I'm going to toggle. I have a lot of results here. So I'm telling the system, I only want to see the VM deploy times, right? So I'm filtering the values. So as you can see here, I have around nine heads for the VM deploy times. And the average time, like how much VMs actually took to boot, let's sort that. And as you can see, the first result, like the least one, it's the better. And when I look this up, I say yes, I was using Cinder at that time. So the idea here is like you get a result and then you go into each result and dig, what did I do, I did different this time. So this is will be the mechanism. As you can see, there is not that much difference when it come to, this is a result for Q code to format versus row. Like they were like almost the same. So not that much difference. At the end of the day, like it depends on you whether that's a lot of difference to you or not. So this is one thing. So moving to the second question, now we are seeing how our application was affected by changing the format. So here, this is our application names, like we are using a small dataset, we call the test boos small. So I'm filtering for the values here. And again, I can see a really good result over here comparing to here. And when I look it up, again, I see Cinder. So even if your configuration is wrong, even if your configuration is right, the thing that you find what is suitable for your storage from your data. So like you are mining the data and capturing all your benchmark result in order to design the best storage, in order to make the best decision whether to go with that vendor or that vendor, et cetera, et cetera. So like this, as you can see, we didn't want, we didn't go to the way where we are like reviewing gigabyte per second and in a very technical terms that only a storage administrator can understand. So in this result, like even business people can review and make the decision. You can go to your user or you can go to your manager and say, well, if we purchase this SSD or if we go with DDN, we can get this time, as simple as that. And you can make decision based on that result. So going back to the presentation, just to get you like the workflow that and how we got those results, what is that? It's all of them open source tools that we glued them together to get this result. So we started with a heat, just like a heat, which is the orchestration engine for OpenStack. We kicked out the VMs, deployed them in the hypervisors. And then later on, some of the, a couple of Ansible Playbox that run our actual job. So the Ansible Playbox run our actual job, which is that scientists really care about, like their genomics workflow. It can be in your example on MySQL, it can be any application. So the Ansible here, just to control the application layer. After that, once you get the result, you start in a JSON format. And it is the format that is the system, the Elasticsearch understand it. The Elasticsearch component here, it's the component that we use to ingest those results. So we are capturing the result from the VM deployment time. We are capturing the result from the application runtime. And we ingest them into an SQL-based cluster that's indexing our result. And then the last stage, which is what we did, is discover with Kibana. So the Kibana is just a front-end geographical interface to view your index document. You can query your results in APIs in different tools. The important step I see here that you need to take action based on that result. So you're gonna like benchmark all day, you're gonna like plug this into your BOC and then view the result and later on make an action based on that results. Just couple of things to consider, things that we did while working on this, like understand the ab metrics. If it's time, like in our case, when we talked to the scientist and said, how we can understand if your application will move faster? They said, okay, the less time, more is the faster for us. So you need to understand the application metrics. Is it like by the number of transactions? Is it by time, et cetera, et cetera. Depending on your application, you will have a different metrics. So make sure you understand the metrics. Second, that include as much data as possible, meaning that it's the end of the day. So make sure you capture the network status, the system status, the cluster status. Any data can be useful if you link it together. If you start filtering for value, if you are starting asking another questions, because every time you're gonna see an answer, another question will bob out or you can have another question from your manager that you need to mine the data again and again. So you're gonna iterate and repeat until you reach to a conclusion. One summary that I think about there, just like this solution or this approach will help you during benchmark, will help you during like choosing a new technology, tuning a different parameters. You see like in every file system, there is a thousand, like hundreds and hundreds of parameters that we don't know if we turn it on or turn it off or change the number, how our application will be affected. So by having this approach, we can understand each little thing we do in the bottom up, we can see its effect on the application layer. Finally, make sure you check DDN Grid Scalar. It can pretty much do everything. It's all in one storage for OpenStack. So basically we have all the four drivers, Manila, Cinder, Object and Glance and it can do Hadoop as well. It's a high performance storage. Thanks to my colleague, Maria. This work was impossible without her. Also the team at University of Birmingham, Simon and Redslow. It was really a joint effort on the whole benchmark. Any questions? Okay, thank you.