This comes up a lot in my conversations with Customers, Prospects and Partners. Delivering 99% of the IO from Flash is one of the biggest differentiators for Tintri that allows us to maximize the value of Flash, delivering sub millisecond latencies to workloads.
One of the toughest jobs for any product that has both spinning disks and Flash is to keep the Flash filled with meaningful data in order to maximize the IO from Flash. This is something that the engineering teams really struggle with, resulting in products that deliver less than 50% IO from Flash in real life situations.
Tintri delivers this with the help of four key technologies –
- FlashFirst Design
- Inline Compression and Deduplication
- VM Granular IO Tracking and Working Set Management
- Block Demotion based on least Frequently accessed data Vs FIFO or Recently accessed data.
Flash First Design…
Tintri with its Flash First design works differently as compared to some of the Tiering solutions. The data is written and retained on Flash and then moved to SATA based on a very granular working set management, which we will discuss later in the post. It is unlike some of the other implementations which use spinning disks for initial placement or just copy the contents to Flash on initial write to avoid read miss on initial access.
Inline Deduplication and Compression …
Tintri utilizes inline deduplication and compression for multiple advantages. It not only allows Tintri to avoid write amplification but also help it maximize the amount of data that is kept Flash. The typical space savings that we have observed on the systems reporting back to Tintri ranges from 5x-10x resulting in a Flash to spinning disk ratio that ranges form 1:1 to 1:2. Vs 1:20 that you see on most of the platforms out there. This helps the system in a big way as the data can now be retained on Flash for a very long time.
VM Granular IO Tracking and Working Set Management…
What we discussed above was the easy part. The more complicated and difficult part of getting 99% IO from Flash is the granular working set management at a vDisk level. Tinri assigns Flash at a vDisk level. Every vDisk has a portion Flash assigned to it. Something similar to server side flash products where you manually assign Flash capacity to VMs. The only difference being that this is done at the storage level and the allocation changes dynamically. What helps Tintri here is the ability to track every IO at a VM level. As the IOs come in, they are stored in Flash. The system works on calculating the working set size for the VM in order to allocate the required Flash capacity to it. Below you see two examples.
In the first example, you see a 175Gb+ VM and the graph shows us that it needs around 60GB of Flash Allocated in order to hit Flash 100%+ of the time.
In the second example, we have another VM of 140GB+ in size and the graph shows us that the VM needs only 5GB of Flash allocated in order to hit Flash 100%+ of the time.
These graphs are from real Tintri systems running VM workloads.
Now, this Flash capacity is the reserve per VM but definitely not what it is limited to. The VM can and does go above its reserved Flash Capacity based on how much Flash is available in the system. The Flash capacity reserved is one of the things that the Performance Gauge on the Tintri GUI is based upon. Remember that the system is utilizing inline compression and deduplication to maximize the Flash capacity, reduce the number of IOs and Flash Wear.
When it is time to evict data from Flash, unlike some of the other storage vendors, Tintri evicts the blocks (at 8K granularity) based on least frequently accessed blocks and not based on recently accessed blocks or an algorithm as simple as FIFO. This allows system to ensure that the most important blocks are on Flash and also that any batch process or a wild VM doesn’t spoil the Flash Map.
So as you see, delivering 99% IO from Flash is a fairly complicated task and Tintri simplifies it for the user by auto-tuning the system. The VM awareness helps a lot. And as I have mentioned before, VM awareness is a lot more than delivering the snapshot or cloning functionality at a VM level. It is technologies like these where Tintri differentiates. This needs a storage that is laser focussed on VIrtualized workloads. A General Fileserver has to store .txt/.doc/mpegs/ppt files natively in the same storage as Virtualized workloads and therefore has to compromise. The same is true for any other General Purpose SAN Storage as it is not aware of anything above the storage layer and has to cater to all type of workloads. Tintri uses the VM awareness to reduce the total cost of ownership by delivering sub millisecond latencies without utilizing all-Flash Storage systems.