The KumoScaleTM Analytics Engine acts to continuously optimize the assignment of virtual volumes to physical drives. This helps ensure that KumoScale storage delivers the expected performance to every volume and every client across the data center.
To do this, the Engine maintains an analytic model of each SSD in the data center, calibrated to the characteristics of the specific model of the drive. In addition, it tracks the behavior of each client, or initiator, in the system according to the storage classes of the volumes they own. This includes the characteristics of the workload they present to KumoScale storage, as well as other characteristics, such as the fraction of their allocated capacity that they actually use. These performance models and workload statistics form the inputs to a mathematical optimization process, which is used to compute the best mapping for new volumes, and if necessary, recommendations for migrating existing volumes.
The KumoScale Analytics Engine optimizes the blend of work assigned to each storage node and to each SSD across the data center. It works continuously to utilize all the available capacity and the available performance from each drive, and particularly to make sure that those workloads don't interfere with each other.
/Analytics-Driven%20Mapping.png?width=546&name=Analytics-Driven%20Mapping.png)
One example of optimizations made possible through KumoScale Analytics Engine is the reduction in interference caused by so called “noisy neighbors,” or workloads that generate large volumes of write traffic. Due to the unique characteristics of NAND flash memory, a heavy write workload on one volume can dramatically affect the read latency distribution experienced by other volumes mapped to the same SSD. Reads that normally might be returned in a few hundred microseconds can occasionally be delayed by milliseconds due to this phenomenon.
KumoScale Advanced Storage Class specifications allow users to indicate whether their application is highly sensitive to these long-latency reads. The Engine uses historical usage data to identify storage classes which are the most prolific noise generators, and attempts to keep the volumes owned by “noisy” and “noise sensitive” applications apart.
