Waves of innovation and waves of companies, crash on the storage market, but the same incumbent leaders and product lines survive for decades. Are things changing? It’s hard to see sometimes, but real progress has been made.
Virtualization of server, network, and storage services illuminates the link between physical resources and functional applications. A running virtual machine can instantly move from one server, network adapter, HBA, or LUN to another. And when it happens, traditional components have no idea how to react.
I stepped into a hornet nest this week when I posted a write-up about a new flash storage array from Pure Storage. The controversy had nothing to do with the underlying technology, which seems quite sound. Rather, it was all about pricing, with Pure’s competitors calling foul on their price comparisons.
VMware’s vStorage API for Array Integration (VAAI) is one of the most-important storage technology advances of the decade, allowing the ESX to integrate and coordinate operations with supported enterprise storage arrays. IBM was notably absent from the party, but they’ve turned on the VAAI heat, releasing full support for the XIV and SVC and promising DS8000 in the near future.
So there it is. Intel’s Light Peak was launched as Thunderbolt in the new Apple MacBook Pro line. What else happened?
Although the core issues with thin provisioning revolve around communication, it presents unique challenges to the storage array as well. We talked about granularity of pages, and the comments for that piece were extremely enlightening. Now let’s consider another key factor: Scheduling.
The most exciting enhancements in VMware vSphere 4.1 is the addition of vStorage API for Array Integration (VAAI). This new API allows VMware ESX to offload storage processing functions to capable storage arrays, reducing the workload on the server hardware in introducing new and exciting possibilities for performance and efficiency. VAAI in ESX 4.1 includes three separate capabilities: block zeroing, full copy, and hardware assisted locking.
Although I consider it the main stumbling block for thin provisioning, communication (or lack thereof) is being addressed with metadata monitoring, WRITE_SAME, the Veritas Thin API, and other ideas. But communication isn’t the only issue. Let’s talk about page sizes. You’ll often see vendors tossing this “softball” objection at their competitors, claiming that their (smaller) page size makes for more-effective thin provisioning. And that’s true, to a some extent.
It’s been a slow week (the holidays) and a crazy one. I’ve started pouring out the thin provisioning series, with 10 posts so far, as well as launching a new video “talk show” about enterprise IT. And I’ve got a new post over at SearchStorage, too. Whew!
If WRITE_SAME can be a semaphore for thin un-provisioning, what about TRIM? It sounds like a perfect fit, and has wider implementation to boot! Let’s take a deeper look.