Hi Tom, thanks for the welcome
. I do want to point out that while I am encouraging Rob to test the array in his environment, this is mainly because I don't have any customers in my territory running Progress on Nimble. Otherwise, our first option would be to have him speak with those customers (without me present) to see how things work in a production environment that has been running Progress for months/years since most evaluations are limited in terms of how much time customers have to dedicate to this testing, as well as how much of their environment can be tested in an evaluation scenario. If this was SQL or Oracle, this would have been our first suggestion as I do have several customers running those databases. I run evaluations in less than 10% of our projects as a result of having these existing reference customers. So, evaluations are definitely used, but less frequently as we build a more diverse customer base.
I will try to answer your questions in the order posted:
1. How can we tell if the compression is being done correctly?
I may have over-simplified my initial comment on in-line compression, but basically, if it is NOT being done correctly, you will see performance degradation, indicated by higher latency. So, via our built-in performance monitoring graphs, you can track real-time the read/write latencies, IOPS, MB/sec characteristics of any or all volumes. If latency is going up, it could be an indication compression is the problem. It may not actually be compression, but more likely CPU resources on the controller, since that is where compression takes place. How can you verify? We also provide a portal called InfoSight, that ingests a multitude of data points from your array on a daily basis via what we call heartbearts (sent approx. every 5 minutes) and autosupport (reports) and analyzes them. It then provides graphs showing you how the SSDs and processors in the controllers are performing, including a heat-map of read/write latency every hour of the day going back months. An example of not doing compression correctly might be taking a group of writes/blocks and compressing them as a group, instead of compressing each block or IO individually and then putting it in a container or larger group. If the former is done, one problem is that if you want to read back a single block, which is often the case, you must first read back the entire group, uncompress, then extract the block you want. This will almost always cause performance issues. Nimble compresses each block separately before putting them in the larger containers to be sent down to disk.
2. Data coalescing with random IO environments - how can this improve performance?
This is actually the best environment for a filesystem with characteristics like Nimble. One key point to understanding how this is possible is, you need to be aware that Nimble does not use a traditional "write-in-place" filesystem. What that means is, once you write a database block, if you want to modify it, Nimble does not need to actually overwrite the block in the exact physical location it was originally written to on the physical disk. We use a log-structured filesystem. So, once the block is first written, if it needs to be modified, we write it in a new location. The more random the IO pattern, the better Nimble performs compared to traditional write-in-place architectures since if it is all sequential IO, you are basically just streaming sequential writes to disk, which might be similar to a backup, and backups work pretty well on slow disk. In essence, Nimble is converting random IO, which is very disk intensive, to sequential IO, which is not. I didn't mention this before, but we only use 7200 RPM drives for our main disk subsystem along with SSDs for read cache only. Why do we use these 7200 RPM drives? Because their sequential write performance is similar to that of 15K RPM drives, and you get much more/cheaper capacity with them.
The challenge to this architecture is cleaning up after ones-self, ie if we are not overwriting existing blocks, if you don't clean them up, the system will run out of space? A built-in sweeping process continuously monitors existing containers and cleans them up when enough blocks in the container are no longer valid. This is part of normal system operation and does not impact performance until the array is just about at 100% capacity. We do not cache writes to SSD, they are streamed directly from controller NVRAM to spinning disk. So, via the coalescing and compression, we get great write performance, and then using caching algorithms to populate the "hot" blocks on SSD as a read copy, random read performance benefits from these much faster disks.
You are correct in saying that RAID6 will eventually cause performance issues, but that will only occur if/when the disk component becomes the performance bottleneck. Today, the bottleneck in a Nimble array is the Intel processor in the controller, so it is not spindle-bound for performance, but processor bound. And as you know, processors are always getting faster, at least for now. To prove we are processor-bound today for performance, we can look at our two models. The CS200 series comes with a single quad-core processor, and the CS400 series has dual hex-core processors. Other than a bit more RAM in the 400 series and these processor differences, the arrays are identical - same spinning disks and SSDs. The CS400 is capable of 3x more random IO than the CS200 series. At some point using the current disk architecture, the Nimble arrays will become spindle-bound, so we will need to adapt to that situation when it arrives but for now it hasn't happened.
Regarding tools to measure coalescing, we don't specifically identify how many IOs are placed in each container before being written to disk, as this might be a little too labour intensive and the array would spend more cycles telling you how it is doing than actually doing it's job of serving your IO requests. But with the tools described above showing IOPS, throughput, latency, etc. it is fairly easy to get an idea of how well the coalescing is doing. We only run a very small amount of NVRAM (protected memory on the controllers) so in a busy environment, it is definitely not able to service up all write requests, hence the disks themselves are directly involved in the latency results. We often have customers run benchmark tests on their current storage, then on Nimble and more times than not, the results are compelling.
