With the introduction of VMware’s VSAN product (official GA was March 12 2014), I’ve been spinning some free cycles trying to understand the mechanics of this product.
The details of VSAN striping, provisioning, and cache behavior are hard to find. I have broken down the key unknowns into 3 general question subjects. Please provide any insights you may have, for sharing with the community.
Question Subject #1 – Stripe Layout and Thin Provisioning (Stripe Filling)
- Layout on HDD: Do VSAN’s 1MB stripes correspond to 1MB of physically contiguous space on the HDDs (minimizing seek times) ?
- Blocks within each stripe: Does each stripe contain an ordered and defined address range of logical blocks for the object? This subject is particularly relevant as VSAN supports thin-provisioning space efficiency.
- If there are scenarios where logical fragmentation can occur (non-contiguous blocks within a stripe), does the VSAN implementation ever “defragment” them? EMC has suggested thick-provisioning pooled LUNs on VNX, and iSCSI LUNs for Isilon, to avoid fragmentation resulting from thin provisioning.
Question Subject #2 – Block Size / SSD Read Cache Page Size
- What is the block size of VSAN? I estimate that it may be 8KB, but that could wrong.
- Does VSAN cache hot blocks in the SSD read cache in full 1MB stripes? Or does it use a smaller, more finely granular, unit?
Question Subject #3 – SSD Read Cache Pre-Fetch / Pre-Warm
- Writes to any object in the VSAN datastore are always staged in SSD (the SSD write cache essentially replaces the role of a battery-backed NVRAM). When destaging to disk, can VSAN let them remain in the SSD to effectively “pre-warm” that data in the SSD read cache?
- Does VSAN have the ability to detect sequential read access to an object, and pre-fetch blocks of data that would likely be read next ?
Thank you for reading – looking forward to your insights!