Accelerating VAAI

This post originally appeared on Juku but I find it technical enough to be featured in my personal blog

By now everyone and his dog already made a post about VAAI, I would not bother you with an extensive explanation of what is VAAI and why it’s crucial to Virtualization, I will simply refer to a couple of posts that explain its current implementation in details:

• Duncan Epping
• Bas Raayman
• Chad Sakac

My focus will be on how I envision to accelerate VAAI even more, enhancing its storage side.

To explain my point of view I will do an analogy with a common feature found in storage arrays today: Point-in-Time Copies.

Point-in-time copies (sometimes referred to as Snapshots) are a really valuable feature, they provide a consistent point in time of a specified Data set in order to perform various tasks like: backups, environment duplications and so on.

Traditionally PIT copies were made using a technique called Copy-On-Write which is suitable for a small number of PIT for a single LUN but its performance issues take their toll as soon as their first PIT is created, PIT copies concept was pioneered by IBM with its FlashCopy functionality.

NetApp innovated the approach to PIT copies using a different pointer-based snapshot technique, this almost completely eliminated the performance issue and made possible a massive number of multiple snapshots per single LUN enabling the complete potential of the PIT concept, this post explain how the Compellent Storage Center pointer-based snapshots works in detail, however this is not specific to Compellent, almost all the next-generation storage arrays (like IBM XIV, NetApp FAS, 3Par InServ, Dell Equallogic, HP Lefthand and many others) use the same approach.

So basically we have a great concept (PIT copies) but with most of its potential still locked by its implementation (Copy-on-Write) and then we have an innovator that enable its full potential with a clever implementation and I’m pretty sure that VAAI is still in its “Copy-on-Write” stage of life .

As you already know VAAI is implemented using an extended SCSI command set, Let’s take as example the most sought-after feature: the Hardware Offloaded Copy.
The hardware offload copy in my opinion can be accelerated to 100000x making all the cloning tasks a matter of few seconds, here’s how:

Keep in mind how a pointer-based snapshot works and bear with me with my explanation:

A 16GB VM sitting in a 128GB Datastore is currently accessed by an ESX host.

Then a VAAI-enabled Clone request is issued by the host, the storage array, instead of doing a real block-to-block copy, simply create a “map” of pointers of the cloned VM on another portion of the datastore, locking its space but without issuing a single block copy, this operation should take the same time as a normal snapshot: few seconds.

Then the host start to write to the new cloned VM and the delta differences are stored in the blocks locked by the “map” previously created.

A similar task can be already done today using snapshots, but it becomes cumbersome immediately because every clone needs to reside on its own LUN and datastore, this approach, instead, can be applied “inside” a datastore streamlining the deployments. Just imagine a VDI infrastructure relying on such cloning technique! .

I’m sure that storage vendors will try to integrate and innovate their respective VAAI implementations, I hope this post made you realize how powerful can be the still-evolving VAAI approach.

Technorati Tags: virtualization, VMware, VAAI, storage

How Compellent Storage Center works – Part 2

Here we are again with How Compellent works part 2, I’m writing this post just after a lucullian easter lunch with my whole family so please forgive some of my expressions

In the last post we talked about how data is written into PAGES and progressed using Storage Profiles and Data Progression, this time we’ll focus on how Replay works.

Replays are, in fact, snapshots of your volume data at a certain point in time, to apply this concept to the PAGES that Storage Center uses there’s another metadata on each, which identify the category of the PAGE, the categories are:

• Accessible Recently Accessed – These are the active pages the volume is using the most
• Accessible Non-recently accessed – Read-write pages that have not been recently used
• Historical Accessible – Read-only pages that may be read by a volume, applies to Snapshot Volumes only
• Historical Non-Accessible – Read-only data pages that are not being currently accessed by a volume, applies to Snapshot Volumes only, Snapshot maintains these pages for recovery purposes and they should be placed on the lowest cost storage possible

(the descriptions are copy/pasted from a Compellent document)

Let’s see with a simple graphic how it works, let’s see how a Volume is represented inside Storage Center when a Replay is taken, each blue block is a 2MB PAGE:

According to this diagram when the C1 PAGE has been written the old C Page change its state to Historical Non-Accessible, meanwhile C1 is an Accessible Recently Accessed PAGE, all the other PAGES that resides below the Replay separator are Historical Accessible PAGES.So in this case, the C PAGE will be automatically demoted during the first Data Progression Cycle to a lower cost storage.

In this graphic another Replay is taken, as you can see, even with multiple replays only the changed PAGES are allocated as new, in this scenario the C1 PAGE and E PAGE becomes Historical Non-Accessible PAGES.

Here is the Replay expiration, the expiration could be manually or scheduled, during the replay creation you can choose between a “never expire” Replay or a scheduled expiration, that can be eventually changed on the fly. The grey tinted PAGES are pushed toward the new oldest replay available, meanwhile the orange tinted PAGE is released back into the pool, to be immediately available for other purposes.

But what if we need to access data of a single Replay? maybe map it to another server to replicate the production environment?Here comes the VIEW.Now the graphic is getting complicated, in the following diagram we see the upper part which represent the VIEW created from a Replay which is in purple, and the lower part which represent the Volume with multiple snapshots like the examples above:

Here we have created this VIEW and mapped to another server (every VIEW is R/W) where we decided to create a new development environment based on production data that we snapshotted using a Replay, now every READ operation goes through the Replay like the arrows say, if there’s the need to write a new PAGE it will be written in the VIEW space, consuming in fact only the ∆ changes.Now the development environment has the need to be snapshotted itself, can we do it? OF COURSE we can , let’s see with the usual diagram how it works:

So you can clearly see how this technology is really powerful and space-savvy, it is also applicable recursively so you can create a view made from a replay of a view which is a view of a replay etc… etc…Next time I’ll take care of the replication with QOS and deduplication, as always feedback and comments are very welcomed!.