February 15, 2016 at 16:39HPE Smart Cache: are you speeding already?
Data caching is not new to disk subsystems of servers or storage systems. As you know, a cache is an intermediate link between data and a disk subsystem. Considering that fast-access SSDs are already quite firmly entrenched in our life, the use of All-Flash subsystems is still not accessible to everyone for one reason or another (mainly economic, because all theories about the low reliability of SSDs are not received any serious evidence). But the desire to speed up the performance of its storage subsystem, organized on classic HDD disks, is still present and is in our time more necessary. Due to the fact that the size of the cache is of considerable importance, an increase in its size will only be beneficial for highly loaded systems. This is where the SSD cache comes to our aid.
Almost all manufacturers of RAID controllers have already introduced controller models that support SSD caching, and today, we will look at how this was implemented by HPE based on its HPE Smart Array P440ar controller .
And so, as an experimental system in my hands is the HPE ProLiant DL380 Gen9 in the following configuration:
Hard drives were assembled in Raid10, and testing was carried out, respectively, in two versions - with and without HPE Smart Cache (using the controller cache, 2Gb).
I think that those who were interested in this topic have long been familiar with the Intel S3700 drive. He came out a relatively long time ago and proved to be extremely positive. The company itself classifies them as the highest class - High Endurance, and in fact recommends them to be used for highly loaded tasks such as OLTP, VDI, Big Data, and for caching data less expensive - Value Endurance, but as they say - what we have. In any case, it certainly won’t be worse, but for end users, this, of course, will increase the cost of configuration. In any case - you are free to use absolutely any SSD drives, HPE gives a recommendation only on their volume - it should be 5-10% of the capacity of your array. It is also worth mentioning that not all controllers support HPE Smart Cache, and younger models of controllers lack this feature. Smart Cache will also work only on servers of 8 and 9 generations, i.e. to increase the performance of the disk subsystem of old servers - it will not work, but it's a pity.
HPE Smart Cache in the current implementation allows you to cache both read and write operations, therefore, it does not have any restrictions and can be used for any applications that exchange information with the disk subsystem.
And so, let's move on to the numbers. Due to the extremely limited time for testing, they will be limited to using only the iometer.
For this test, the most “complex” and resource-intensive test was chosen - the Database. Test Configuration:
In a situation as close as possible to a combat situation, we can see the advantage of using the cache in all respects, both for reading and writing. At the same time, the response time is also an order of magnitude lower, which is extremely important for resource-intensive OLTP applications.
As for the "classification" of the SSD cache in the hierarchy of accelerated performance of the disk subsystem. In principle, we have three ways for this. The first is the topic of our today's material - SSD cache, the second is the transition to All-flash, and the third is the so-called IO accelerators, which I already talked about and tested about at one time - Huawei Tecal ES3000 , Fusion-io ioDrive(which HPE also offers under its logo), etc. These devices are able to further increase the processing speed of your data, but the cost of these solutions will be an order of magnitude higher than using a cache on an SSD. Perhaps it is the most profitable in terms of price / performance.
Summing up, we can say that if it is necessary to increase the performance of the server’s disk subsystem, at the lowest cost, the use of the SSD cache is justified. At a relatively low cost of this solution (the solution itself includes the SSD + license for HPE Smart Cache for the controller, and it is also worth noting that if you have several RAID controllers installed in the server - the license is purchased separately for each of them), we get a significant increase in performance.
And so, as an experimental system in my hands is the HPE ProLiant DL380 Gen9 in the following configuration:
Processor: Intel Xeon Processor E5-2643 v3 x2
Memory: 8Gb x4
HDD: 600GB SAS 15K x4
SSD: Intel S3700 400Gb
Hard drives were assembled in Raid10, and testing was carried out, respectively, in two versions - with and without HPE Smart Cache (using the controller cache, 2Gb).
I think that those who were interested in this topic have long been familiar with the Intel S3700 drive. He came out a relatively long time ago and proved to be extremely positive. The company itself classifies them as the highest class - High Endurance, and in fact recommends them to be used for highly loaded tasks such as OLTP, VDI, Big Data, and for caching data less expensive - Value Endurance, but as they say - what we have. In any case, it certainly won’t be worse, but for end users, this, of course, will increase the cost of configuration. In any case - you are free to use absolutely any SSD drives, HPE gives a recommendation only on their volume - it should be 5-10% of the capacity of your array. It is also worth mentioning that not all controllers support HPE Smart Cache, and younger models of controllers lack this feature. Smart Cache will also work only on servers of 8 and 9 generations, i.e. to increase the performance of the disk subsystem of old servers - it will not work, but it's a pity.
HPE Smart Cache in the current implementation allows you to cache both read and write operations, therefore, it does not have any restrictions and can be used for any applications that exchange information with the disk subsystem.
And so, let's move on to the numbers. Due to the extremely limited time for testing, they will be limited to using only the iometer.
For this test, the most “complex” and resource-intensive test was chosen - the Database. Test Configuration:
Disk Size - 209,715,200 (100Gb)You can familiarize yourself with Database patter here.
# of Outstanding IOs - 256
In a situation as close as possible to a combat situation, we can see the advantage of using the cache in all respects, both for reading and writing. At the same time, the response time is also an order of magnitude lower, which is extremely important for resource-intensive OLTP applications.
As for the "classification" of the SSD cache in the hierarchy of accelerated performance of the disk subsystem. In principle, we have three ways for this. The first is the topic of our today's material - SSD cache, the second is the transition to All-flash, and the third is the so-called IO accelerators, which I already talked about and tested about at one time - Huawei Tecal ES3000 , Fusion-io ioDrive(which HPE also offers under its logo), etc. These devices are able to further increase the processing speed of your data, but the cost of these solutions will be an order of magnitude higher than using a cache on an SSD. Perhaps it is the most profitable in terms of price / performance.
Summing up, we can say that if it is necessary to increase the performance of the server’s disk subsystem, at the lowest cost, the use of the SSD cache is justified. At a relatively low cost of this solution (the solution itself includes the SSD + license for HPE Smart Cache for the controller, and it is also worth noting that if you have several RAID controllers installed in the server - the license is purchased separately for each of them), we get a significant increase in performance.
