 Hello, everyone. My name is Karina Angel and I'm here with Michael St. John and Sige Volkov from the Red Hat storage business unit, as well as Yana Wong from IBM. And we're here to talk about IBM DB2 warehouse on OpenShift container storage. So I'm really excited about the performance test that they've been doing on OCP and please, Michael, take it away. Thanks a lot, Karina. Yeah, so today we're going to talk a little bit about I'll give a little introduction to DB2 with Red Hat OpenShift. And then I'm going to turn it over to Sige and Yana to talk a little bit more about the testing that was done and the performance results. So let's go ahead and get started here. If you're not familiar with DB2, well, I think you should be because DB2 is actually one of the industry's leading database platforms. A lot of very critical workloads run on DB2, as well as being able to be deployed in multiple different ways. So if you think about it from an OLTP perspective, let's say you have cloud native developers that are developing applications that needed a relational database. DB2 is a great piece for that. And then as well, DB2 can be used as a data warehouse, symmetrical multi-processing type deployment as well as a multiple parallel processing deployment. So if you have vent store, which is a in-memory database, can be deployed on the cloud or through cloud pack for data. So for our testing, we looked at DB2 warehouse. DB2 warehouse includes a built-in machine learning, as I mentioned, both SMP and MPP processing, and in database analytics combined with this IBM VLU acceleration. What we did here was we used DB2 warehouse multi-parallel processing for our tests. And typically, as we look at that, we have a lot of customers who are looking at business intelligence type workloads, AIML type workloads. And so we wanted to focus in on that. But as well, we felt that the DB2 warehouse MPP tests would give us a good indication because they're very complex workloads. We thought that it would give us a good indication of how well DB2 works in an OpenShift environment with OpenShift container storage. And then as well, we're looking at this from a hybrid data warehouse perspective. So you're able to do rapid data retrieval and you have flexible deployment and scalability, regardless of how you're deploying that implementation. So as we look at why people are considering running DB2, because typically you think about some of these databases running in a traditional on-prem type of environment. Why are people looking to modernize their data infrastructure and move DB2 to more of a containerized development environment? Well, if you look typically right now in the industry, about 71% or more of organizations are planning to containerize existing applications. And so for the past few years, IBM has been doing a lot of work to make sure all of their software applications are running in a new modern containerized environment. And you see this a lot with customers who are trying to modernize and build cloud native with their application development, application deployment, and now a lot of those machine learning and data intelligence types of applications. So why is DB2 as cloud-native database important? Well, first of all, we have the ability to do very rapid deployment. If you think about, and if you're familiar with OpenShift and the OpenShift operator, you're able to deploy your applications much faster. With a DB2 operator, you're able to do a very quick deployment to a worker node. You have simplified lifecycle management. So as, you know, in your date two operations as new application versions come out, it can be automatically updated. So you have a much easier update process, which gives you, if you see in the middle and the bottom, faster delivery of new features. And then DB2 services can be deployed as microservices. And as I mentioned, these day two operations, they can be developed, they can be spun up, they can be updated and scaled independently. Right. And then we have that flexibility that I alluded to for, you know, on-prem or across private clouds, public cloud type of deployments. So what are some of the key benefits? I mean, typically if you're looking at like an OpenShift containerized type platform, this reigns true with delivering your DB2 environment as well. It's, you know, it's all around agility. So being able to deploy DB2 when you need it, where you need it. So one of the key benefits now is that your data scientists or application developers don't need to go back to an administrator to get resources for their projects. They can spin up projects very quickly, very easily. They can spin up sandbox type of environments. If they don't like something, they can just trash it and it all gets done automatically within the Kubernetes infrastructure. So this is a great deployment strategy for people who want to take advantage of DB2. And then from a scalability perspective, running on OpenShift container storage, we saw, we see and we'll show you in some of the testing that we did that we meet or exceed resource utilization, scalability and performance expectations across the board. And then it's also about reducing the complexity. So with OpenShift container storage, we provide the data services that are provisioned just like you would provision compute resources for the DB2 application, and it's all done within one unified control plane. So what is some of the technical differentiation that we see? Well, you know, by doing a lot of the testing internally with IBM, we have a validated solution so you can trust in the reliability and the performance of the environment. So, you know, as you look for example, IBM has done a lot of testing around these solutions with other storage environments. So they have a good idea of what works, what doesn't work, what performs well. And this is why we're coming to you today. We want to tell you about the great performance and the exceptional deployment experience that we had, right? And then from a security perspective, there's a lot of security already built into IBM DB2, but also by using OpenShift and OpenShift container storage, we have very strict standards for security. So you have a very secure storage layer for DB2 across that entire environment. And then from a lifecycle management perspective, I already kind of talked a little bit about this, but OpenShift container storage is designed and tightly integrated in with Red Hat OpenShift. So you have a consistency across your user experience and that type of environment, and you're able to manage your compute resources for the application in this case, DB2, as well as your storage layer independently. That brings us to the next point here, being able to independently scale your database resources or your application resources from your storage performance. And then what does it mean to you typically? So if you take a look at it from a big data or analytics AIML director's perspective, you know, running IBM DB2 on Red Hat OpenShift container storage gives a big data director the ability to scale storage as their needs increase with reliability and performance and the ability to utilize Red Hat OpenShift to run both DB2 and the storage that supports it makes operations more efficient and better utilizes existing IT skills that you might have already in your IT department. From a data architect or data engineer perspective, think about OpenShift and OpenShift container storage, providing more of a modern data architecture that's based on containers and the Kubernetes orchestration. The whole platform can be configured to be highly resilient and it can scale without arbitrary limitations, right? So data can be hosted redundantly across multiple geographically distributed availability zones or failover zones to provide business continuity and a rapid disaster recovery for that type of environment. And then from a data scientist perspective, supporting IBM DB2 on OpenShift container storage empowers the data scientists to innovate without artificial constraints or without constraints placed on it by the storage administrator. So with Kubernetes operators, data scientists can work entirely within Red Hat OpenShift to program their infrastructure for both the DB2 application and Red Hat OpenShift container storage so they can focus on innovating, focus on their solutions and not worry about the underlying infrastructure. And here we have a quote from Piotr Mirzyzewski. He's the director of DB2 development for IBM data and artificial intelligence. One of the great things about this implementation is with no prior experience with OpenShift container storage, they were able to ramp this up within a couple of weeks. You know, they actually thought that it was going to take them a lot longer without any prior experience. It took them about a week to set everything up. Another week to get everything tuned up in the test ready. And you'll hear more about that from Yana and Segi. So I'll pass this on to them to talk a little bit more about the test layout. Thank you Michael. Let me share. I like how we all look very young in the picture that you put in there with the last quote. Me and Yana are going to talk about the actual testing that was done. I'll concentrate on the layout of the cluster of the OpenShift and OCS cluster. And Yana will talk about the results. So we have decided to use the data warehouse version of DB2 for a few reasons. First of all, it's designed to do massive parallel processing of data. So we want something that will hammer our storage, the OpenShift container storage as much as possible. It's also pretty much what IBM usually use when they test a new storage subsystem, the data warehouse version. And the end of this long DB2 WHOC means on the cloud. And the reason we decided on the cloud was, well, everyone is doing something on the cloud. And also it was in terms of a constraint of what we could use at this point of time, the cloud was easier to do. As you can see in this slide, there's a few calculations that are being done in trying to basically match a DB2 data warehouse to the cluster that you are running on. Each in the past would run a partition of the data warehouse, what is called a logical node or a multi-logical node, an MLM. And there's a few calculations that need to be done, minimum of 8 GB of RAM per core of whatever you are running. You can see it all in here. The other part of this equation is that we also looked at the OpenShift best practices and it says, leave 2 CPUs per node and 8 GB of RAM per node for OpenShift. The rest you can use for your application. So with that in mind, as I said, we decided on AWS. This is a seven node OpenShift 4.3 cluster. It's seven because there's only one master. Don't try this in production, but for a budget perspective, it's easier. We decided to use four nodes of a R5A4X for the worker nodes that are going to run the DB2 pods or the MLNs. And these nodes are known to have a very good ratio in communication bandwidth between the cores and the memory. These are AMD nodes if I'm not mistaken. And we are using three instances that are of the, I think AWS called them storage instances. These are basically an AWS instance that has directly attached to it or supposedly directly attached to it to NVMe devices, 2.3 terabyte NVMe devices. So our OpenShift container storage cluster is basically formed out of these three nodes. Each of them has two storage devices, gives us a total of six devices. And we ran our initial test on everything on a single zone. So doing all of this calculation of how much we need to keep on the, let's call them the DB2 worker nodes, how much we need to keep for OpenShift. Basically gives us this amount of requirements that was used for each of the MLNs or the DB2 partition pods. And the total of the DB2 capacity for DB2 compute nodes for MLN, 52 CPUs and 416 GB of RAM. This is how it looks basically in a nicer diagram. On the top, the four OpenShift nodes that are going to run DB2. On the bottom, the three OpenShift container storage nodes that are going to provide the storage and our single master on the side. For the setup itself, we basically needed what I guess in the DB2 world is called a storage zone, two types of storage zone. One is a shared storage zone. This shared storage zone is using CepFS. Cep is one of the, is the building blocks of OpenShift container storage. And portion of CepFS is or directly is used to share information between the partitions of the DB2 pods or the instances of DB2 that are running on different nodes. Also, the test data was created and stored on a CepFS directory in order to create ones and then upload using external table into all the database pods. And then we have also a zone or storage zone that is not shared that is pair database instance or pair database pod. And this is using Cep RBD, the block device option of Cep. As stated, this zone needs very high performance storage. And so that's why we chose Cep RBD for that. This is a little bit of how DB2 looks in the Kubernetes slash OpenShift world. DB2 is installed as a, or the DB2 MLNs are installed as a stateful sets. There's another version of HCD that runs as a stateful set and basically to track information and heartbeat between the different partitions or the different DB2 pods. There's other pods that are running in the background, some from management, some as a toolbox, but the two most important ones are the top. From the OpenShift Container Storage layout or configuration, when we ran this, we were still running version 4.3. As I said, we used those NVMe devices that the AWS instance provided via what we call Direct Attach Storage. We're using the local storage operator to basically hand out these NVMe devices as PVs. And then OpenShift Container Storage, in return, use those as the building blocks for the Cep cluster and then provide the storage from there. Because the nodes that we use, we want to keep it as cheap as possible, I had to tweak a little bit the CPUs that I gave to other components of OpenShift Container Storage, because we are mainly going to use a little bit of CepFS and mostly of a RBD slash block. So you have the resources that are kind of limited, which basically in future versions, we might have the ability to even control this dynamically. The resources appear different components of OpenShift Container Storage, which will basically mean that we will be able to provide even more performance or more resources just to the RBD portion, allowing DB2 to get even more performance from the same layout. Just another quick diagram of how OpenShift Container Storage basically looks. Those up in the top are basically our, excuse me, our DB2 pods that are running in some nodes. The openShift Container Storage pods, we have several of them. Those many OSDs that you are seeing are basically a pod that gets attached into a storage device that the Cep cluster will use. So in our case, we had six NVMEs, we had six OSDs. The Mons look up on these OSDs, on the metadata on them, provide information on where to read and when from. And there's other pods that are also a part of the OpenShift Container Storage. And with that, I will move this to Yana. All right, let's take a look at performance. So when we look at performance, we basically wanted to answer four basic questions. One is how well does DB2 on Red Hat OpenShift Container Storage perform in general? How well are we utilizing our system resources? How well does the system scale as we increase the size of our workload? And how do we compare to existing cloud-based storage solutions for DB2? Those are the four questions we were going after. In order to answer these questions and to test the performance, we utilized a workload that's called BDI. Finally, I would like to give a little background on what this workload represents to show that it is really relevant as a typical data warehouse application. BDI stands for Big Data Intelligence. It is an IBM-defined workload. And it basically models the life in a business intelligence application where we have a retail database with in-store, online, and cataloged sales of merchandises. The schema of this BDI workload follows that of the TPCDS benchmark specifications, so our standard industry benchmark. And that comes with seven part tables that store sales and store returns, catalog sales, catalog returns, grab sales, grab returns, inventory table. In addition to 17 dimension tables where we store information about the customer data, about the items, about the products, and so on. Interesting with this workload or what we can do is we can generate this database at any scale factor. And in order to analyze the performance of DB2 with Red Hat OpenShift Container Storage, we use a one terabyte workload with scale factor 1,000 basically, which means we work with about one terabyte of raw data or flat files. In order to also see how well the system scales, we also set up a two terabyte BDI workload to see what happens if we increase the size of the data by 2x how does performance change. Now to the query set, so the workload is a query-only workload. It comes with 100 queries that were inspired by Cogniz 10 generated SQL for dashboards and reports. And we basically have three types of users that are represented with this workload. For one, we have the returns dashboard analysts, so that's a person that would investigate the rate of return, the impact on the bottom line of the business. These users run typically very simple queries that can be answered in sub seconds and 17 out of our 100 queries fall into this category and we consider them simple queries. In the second user that is represented, it's like a sales report analyst. He would generate sales reports to understand the profitability of the retail enterprise. These users run more intermediate queries with like one time of up to one minute and 25 out of our 100 queries fall into this category and we call them intermediate queries. And then we have a third user that's the deep dive analyst, so the data scientist, and they use handcrafted deep dive analysis to answer questions identified by both the returns dashboard analysts and the sales report analyst. And, you know, these are very complex queries with several minutes of runtime, and we have five of those very complex queries. Now we have two different ways we can run the workload and we utilize both of those during our, you know, during our testing. For one, it's the serial mode, where we have a single user that basically runs to all 100 queries from beginning to end. And we measure like how long does it take on this particular system to finish running all 100 pairs. There's a second mode that we can run and that's the concurrent or the throughput test mode, where we have a given number of users in our case we use 16 and 32 concurrent users that submit a number of queries or an unending amount of queries of a certain category to the data base for a period of, in our case, one hour. So we want to see how much work can be can get done within a one hour time frame. The queries we chose are only intermediate and heavy queries, not the simple ones because obviously those can screw the picture of the throughput quite a bit. We're looking at it to kind of stress the system by allowing 16 or 30 concurrent users to just put intermediate and heavy queries against the database for a period of one hour and get a throughput of queries per hour. So to summarize what we did for our runs, both on the one terabyte and the two terabytes setup, we did a serial warm-up run. So on a code buffer code to see just 100 queries, we did a serial three iteration run where we run each query three times, measure the total elapsed time for that. And then we have two concurrent or throughput tests with 16 heavy users and 32 heavy user again needs. We're using intermediate and complex variables. All right, we can move to the next slide. One more. That's right. So here on this graph, you can see the overall performance summary. What we here see is on the left, we're looking at warm-up and serial run performance. So the bars in blue represent the results for the one terabyte setup, the bars in purple for the two terabyte setup. And again, we're measuring the elapsed time. How long does it take to run all 100 queries? So the warm-up run for one terabyte took 3.8 minutes. The three iteration serial, 10.87 minutes. For the two terabyte, the warm-up was 7.7 minutes. So about 2x the time of the one terabyte workload, which we would expect because we doubled the data. And then for the two terabyte serial, three iteration months, we had 22.6 minutes, which also is about two times the amount of the one terabyte three iteration months. Now on the right graph, we see the results for the multi-user run-through protests. Important here to note is that we are looking at how many queries we were able to finish within a one-hour time frame. So the higher the bar, the better here versus on the left side, the lower the bar, the better there because we looked at total time. But now on the right, we're looking at throughput. Here you can see that for the one terabyte 16 user run as well as 32 user run, the throughput is between 440 and 460 queries per hour. And as we move to the two terabyte runs, the throughput goes down to 252 and 228 queries per hour. What is nice to note here, which we will talk a little bit about a little bit later too, as we increase the data size by a factor 2x, the performance only goes down by a factor of 1.7x. So we don't even see a 2x drop, which means that the system scales pretty well. All right, please move to the next slide. Now, that was just the overall overview what we just saw. The numbers in itself on one system don't mean that much other than the scalability factor. We need to compare to something and we also need to answer, well, how well does the system utilize its resources? So we took a look at three things. CPU utilization, disk utilization, as well as memory and network utilization. So one of the most important things we often look at is CPU utilization. So we look at, you know, how busy are our CPUs during our runs. We did this for all serial and multi-user runs. We're going to focus here on the multi-user runs because that is more interesting as we look at it. So in this you see on the top, the top two graphs represent the one terabyte CPU utilization. And here you see the DB2 nodes are averaging about 65% during the 16 heavy multi-user run. So there's still room, you know, we're not totally maxing it out. The OCS node, CPU utilization is also fairly low. But as we increase our data volume to two terabytes, we see that CPU utilization goes up from that 65% now to 90% for the DB2 nodes. And we also see an increase of CPU utilization on the OCS node side. So this overall shows, you know, we are utilizing our system resources pretty good. Okay, next slide. Now let's take a look at disk utilization. So, again, the top two graphs represent the one terabyte run results or disk utilization on both DB2 node and OCS node. And on the bottom, the two little graphs show the two terabyte runs. Now, I understand that the picture is fairly small, but it's okay because we only need to kind of see what has changed between the upper graphs and the lower graphs. So on the top for the one terabyte runs, you can see that we have a fairly low disk utilization. I would say maybe around 25% with a few spikes here and there. One thing to note is that the one terabyte setup occupied about 42% of the available disk space that we had, and almost all the data fit into buffer pool. So we would expect to not see too much disk IO because most of the data is in buffer pool and we can rate straight from there. But that changes as we move to the two terabyte run. So when we have set up the two terabyte workload, about 85% of this space was now occupied. And we now only fit about 25% of our data into buffer pool, which means we have lots more disk IO going on. We need to clean pages from the buffer pool, we need to read new pages into the buffer pool. And that is very much reflected on these graphs. So if you compare the bottom left to the top left graph, you can see that we many times reach this business of like 100% even, you know, it spikes in there, but it's definitely much higher. We also see on the right side that on the OCS nodes, we also see the disk utilization increase. One thing to notice, I think Sadie mentioned that earlier, we have run this on 40 between nodes and three OCS nodes. The graph here is representation of one of those, but good to notice also that the disk utilization is very similar across all 40 between nodes and across all three red hat OCS nodes. So that's a good sign that there's no imbalance going on. All right, next slide please. Now let's just take a quick look at memory and network utilization. So they overall appear healthy that they didn't present represent any performance bottleneck. We have memory available to the OCS nodes, as well as the db2 nodes, but again, they don't represent any problems. Overall the ram is utilized as expected. And again, we saw that memory and network utilization is very similar across all four db2 nodes, and all three OCS nodes, which, which shows that, you know, we don't have any school going on. We, we really have a good balance of how everything is working. Again, it's I understand that the picture is very small here, but I'll walk you through it. So the graph in the middle represents the bars, the blue bars show the the run results for the one terabyte setup and the purple ones, the one, the run results for the two terabyte runs. And you could see that, you know, as we increase or double the amount of data, the throughput reduction is only 1.75x, which suggests good scalability. And the reason for that is that during the one terabyte run, we're not running our resources to the max. We saw that CPU utilization was around 60%. As we increase our data, we, we maximize it more to 90 to 100%. We see on the, on the data business that, you know, we go, we utilize our system resources really well. We are reaching often, you know, 90 to 100% disk utilization and also our OCS nodes show, you know, this increase. This is pretty significant. We have been testing with other systems as well in the past and have not seen this great of a scalability. This is really good news for us. Another thing that I want to mention on this part is also that during our four day test window that we had on the system, the perform the system performed really well. We had no unexpected outages, so the resiliency seemed very good. So that was a very good thing. Now, in order to also evaluate how well does the compare performance of Red Hat on, of DB2 on Red Hat OCS compare to existing cloud storage offerings. We have run the same set of tests on different configurations. The one pictured here is one that basically comes closest in terms of number of MLNs, number of CPUs, numbers of RAM that we had in comparison to the Red Hat OpenShift container storage. We measured the, you know, the same type of test, one terabyte and two terabyte BDI workload pictured here is the one terabyte output. We would run the warm-up and serial runs as well as the throughput runs pictured here is the throughput runs, which is again more relevant. And we would, in the end, normalize it. So the cloud storage solution had about 50% more RAM. So we ended up normalizing the numbers. What would it look like if we had about the same number of RAM? The number of cores or CPUs was the same to start with. So when we do that, we can see that we are pretty much on par in those two cases, which suggests, you know, the performance is as expected. It's doing really well. Saby, you can continue from here. This is just the beginning of a journey between OpenShift container storage platform and DB2. All this data is already in a published white paper. And the next white papers are going to concentrate on all sorts of failover scenarios, which from the DB2 customer perspective is super, super important. We're going to do also some bare metal performance and use not only data wellers, but the OTP and OLAP workloads to test everything. And then also IBM Cloudpack for data version 3 will have support of OpenShift container storage 4. And I think that's about it. These are the people that help us besides me and Neanna and many, and Richie and Peter. And we want to thank them as well. All three of you. That was excellent. And we do have some questions. First question is, does DB2 need its own at CD? Yes. For my understanding, it does need its own at CD. It might in the future not have to use that. But right now, and it is super lightweight in terms of resources anyhow. But right now DB2, this is what they use to share information and many status of the partitions between the pods. And another question is, does cloud based block storage? Is that the same as EBS? We could have done this with EBS and that will be mean that for OpenShift container storage as the building block, we would have had to use something like GP2 or I01. Which will either make things extremely more expensive or probably also extremely more slow in the GP2 case. So, I don't know if AWS consider those storage instances as part of EBS, I don't think so. Think of it as an instance that has two storage devices directly attached to it. In OCS, we'd SEF basically create a cluster from this and manage the storage, protect the data, replicate the data and all of this. Thanks. One thing I might just add is, you know, if you're looking at OpenShift container storage, it gives you the file block and object storage protocols. So you don't have to go to like an EBS. All right, another question. In the layout diagram, you showed that you deployed persistent storage on different nodes other than DB2. Can't I run everything together in OpenShift? You can. This goes actually more on the requirements for DB2. And right now, the requirements are for a DB2 pod to consume all the resources on a particular OpenShift node minus all the resources that OpenShift needs. So this is a DB2 requirement. I'm not a DB2 expert on that end. I don't know if they are going to change it. I think it's more of a reflection of the migration from bare metal, where these processes of DB2 we just want to consume as much resources as possible on each server, moving into the OpenShift world or even to the cloud. It's kind of right now continuing with the same line of thoughts. So technically, for sure you can do this. But right now, I think the DB2 requirements are to have the DB2 pod on consume all the resources on each node. All right, another question is the DB2, you're testing on OpenShift. Does this also run in IBM CloudPak for data? Yeah, maybe for those that aren't familiar with the IBM CloudPak for data, it's one of the ways that you can purchase services for DB2. So with the CloudPak, you have a single bundle where you purchase that one bundle and then you can have multiple IBM applications. And DB2 is one of them, both the DB2 OLTP and DB2 warehouse. And that can all be run within that license and then they can all run that within the OpenShift environment. And then in addition, there's this IBM storage suite for IBM CloudPaks that gives you the ability to deploy all your data services, including, it does include the Red Hat OpenShift container storage as well as Red Hat SEP storage for any of the CloudPak environments. So that's an interesting way of purchasing overall IBM services for your environment. All right, another question is, which version of OCP, OpenShift container platform, have we tested this performance? Yeah, so this was OCP OCS 4.3. The next white paper, the next white paper that's going to come up on failovers will be with 4.4. Okay. Are you, the 4.5 is coming up shortly. Are you, are there plans to? We might do 4.5. It depends on the OCS side. On the OpenShift container storage side, but it's definitely going to be 4.4 or something higher. Okay, thank you. All right, let's see. Tests show that you're running in AWS. My data is sensitive and I can't have it sitting in a public cloud. Can this be run on-prem in my data center as well? Of course, it can be, you can run the OpenShift cluster either on bare metal or on some on-prem virtualized environment. And you can do literally the same setup in terms of the OpenShift container storage, provide your bare metal devices to the OpenShift container storage pods. So you're only going to get better performance. Well, I assume that's why that you're publishing your performance tests, otherwise we wouldn't publish them right. All right, I haven't run OpenShift container storage before. Do I need to go to training or send my admins to training? So what's the barrier to entry here? Well, I mean, I think that's one of the great things about deploying in the OpenShift environment. The operators really streamline the day one, day two operations. And as you saw in the quote from Piotr, getting the environment up and running and performing to scale was very simple, even for a team with no prior experience. You know, of course, you know, Red Hat does offer services and expertise if you do need help, but you know, getting up and running day one is pretty fast and easy. And maybe, I don't know if Segi or Yana have something to add to that, but since they run the environment. Yeah, well, I just want to say that the quote that you showed from Piotr is actually when the DB2 slash CP4D team. Was doing their own initial testing and there was no actually involvement from Red Hat at that point. They basically installed their own OpenShift cluster and installed OCS on their own. And that's actually what the quote is coming from. So the environment that we tested on, you know, obviously I know what I'm doing, so I know how to install OCS. But the quote actually comes from a completely, you know, DB2 only separated the team doing their own testing. And Yana? Yeah, I had made the same experience from what you were describing. I have not been on Reddit OCS before, but it was really easy to just get up and running. I mean, I asked probably a few questions, how do you do this and that here, but it was very simple overall. And we only had four days on the system and I think we got more than done than what we expected we would be able to do in the time frame. I think originally we were planning to only do the one terabyte test, you know, but we were able in the end to add a complete different set as well and provide just some more data points that were relevant for the white paper. So are there plans to put kind of a configuration blog together or is there a configuration guide that can just walk people through this or what are your thoughts? Specifically for this, for a DB2 data warehouse environment. I mean, from OCS perspective, we are, correct me if I'm wrong, Michael, we are going to come up with some kind of a sizing configuration guide. And of course, when it comes to storage, things change and varies from the cloud or even any cloud provider and their own specific storage abilities and then to the on-prem, whether it's bare metal or virtualized. So I do think we're going to come up with a sizing guide to help people understand that. Yes, I think that would be good for us to take a look at, you know, so we currently have an internal sizing guide that's kind of based on capacity measures and how to configure the solution across different clusters, right? Adding that perspective of, you know, what do you need for performance? What are your performance expectations and how you should configure what disk you should use, et cetera, et cetera, is helpful. I know that there's a knowledge base of deploying IBM DB2 on OpenShift. There's a knowledge base article around that out there right now. I don't know that it really gets into the storage perspective on that. Perhaps the white paper will help with that, but I agree with Siddhi. We should probably look at adding some more information into our OCS documentation as it pertains to sizing for performance. And do you have any final thoughts that you want people to really take away from this? You have your webinar that's coming up about, go ahead. Yeah, yeah, I just wanted to mention there is a panel discussion with some of the IBM and Red Hat executives that's scheduled for the 28th of July. Unfortunately, I don't have a link to that yet, but I believe it's probably going to be posted out on ibm.com slash events. But in any case, you know, if there are questions around that, you can get back in touch with any of us and we can give you some additional info.