Stephen Foskett, Pack Rat

I had two great storage virtualization seminars this week, in New York and Philadelphia.  As usual, audience participation was key, and interest in VMware and Hyper-V remains high.

One of the main questions I always get is which protocol one should use for VMware storage. My recommendation remains that the answer is an organizational one more than a technical one.  There are certainly performance, CPU utilization, and support differences between Fibre Channel, SCSI, iSCSI, and NFS on VMware, all of these can work fine in many situations.  Although this is addressed in my presentation, I thought it wise to point out some of my sources and (concurring) opinions.

First, I point you to the official VMware VI Team blog, where they reiterate that VMware is protocol-agnostic.  They commit to support all storage protocols equally, and promise to add missing support as soon as possible.  See especially their table of support, which shows that iSCSI currently can’t be used for clustering (!), among other insights.

I’d also like to point out three sources for my seminar slides:

• VMware’s Comparison of Storage Protocol Performance paper, which pits Fibre Channel against hardware iSCSI, software iSCSI, and NFS.
• VMware’s Performance Characterization of VMFS and RDM Using a SAN, which shows that there is a negligible performance difference between shared storage and the two varieties of RDM.
• NetApp’s NetApp and VMware Virtual Infrastructure 3 Storage Best Practices (recently updated), which is a wealth of information on shared storage with NFS, even if you’re not a NetApp customer.

Even though storage virtualization technologies have been on the market for 20 years or more, and numerous companies have tried to sell it as a product in its own right for at least half that long, many are still unsure of what to do with the technology.  A great new piece by Dave Raffo, News Director at SearchStorage.com, discusses the wide variety of virtualization solutions and the real impact they can have.

Dave called me for this piece, and I was pleased with the question.  Truth be told, there really are compelling benefits from virtualization, but most folks have been waiting for a real “must have” killer application for the technology.  In order for this tech to make the impact it should, we in the industry have to change some of our thinking:

• Storage virtualization means more than just Fibre Channel block aggregation.  There are great applications inside servers and arrays and in the NAS world, too.
• Speaking of NAS, Microsoft DFS is probably the most-implemented storage virtualization product, and just about every NAS array has cool aggregation and migration features.
• Virtualization is a feature, not a product.  HDS has seen the amazing potential for block virtualization in migration and storage flexibility, and this is just the tip of the iceberg.
• Storage and server virtualization go well together - so well, in fact, that ESG reports that 24% of those who have implemented the latter are also using the former!

Now that my TechTarget Virtual Seminar on email archiving is finished, I wanted to share the questions and answers from the session here.  You will eventually be able to catch a recorded version of the presentation on TechTarget’s searchexchange.com site, and I’ll post when it’s out.

Interestingly, most questions revolved around justifying the purchase of email archiving solutions.  I didn’t capture all of the questions, but will try to summarize the justification-related ones here.

How can a small company archive email?

Although email archiving is expensive, it is critical to almost any organization.  Luckily, there are options for most people.  At the most minimal, you can roll your own archive by “forking” messages into a redundant email system using mail forwarding rules.  Many folks use open source UNIX mail servers for this since they’re especially inexpensive.  Next, consider Exchange 2007’s managed folders as a way to build a basic but fully-supported archiving system.  Another idea is to think about a managed service - many of these are much less expensive to set up than building a solution in house.  Finally, look around and you might find that there are indeed much more affordable products than the “big names” many people have heard about.

Archiving solutions tend to be very expensive for enterprises, what is the trade-off?

Archiving solutions are very expensive indeed. They are difficult to justify on purely cost (IT infrastructure) basis. You must bring the legal and business people to the table and get their buy-in to justify the cost. Simply put, email archiving is expensive but e-discovery is much more expensive. With the backing of the legal organization, the cost justification looks much more positive.

What should be considered to account for email archiving for D/R scenarios?

Another great question! Many managed solutions include integrated DR for the system, but may not capture messages during a disaster or communications interruption. Local solutions tend to rely on conventional DR concepts like synchronous replication. Again, this technology (and especially the telecom to support it) is very expensive, but the cost can be justified for some when balanced against legal risks.

I’ll post more Q&A from my upcoming Storage Virtualization Seminars in Atlanta and San Francisco as well as my Storage Decisions appearances in the coming months.

One of the hits from my TechTarget storage virtualization seminar this week was a discussion of the relative merits of different storage protocols. Sounds deadly, but this can be quite a religious issue for folks, and it generated lively debate. I’m firmly in the “do what works” camp - there is no always-right protocol, and they all can work.

In the interests of all, I’d like to point out two delicious sources of VMware storage protocol wisdom:

An internal paper from VMware’s performance folks titled Comparison of Storage Protocol Performance shows that, as expected, Fibre Channel has the lowest CPU overhead and best overall throughput. But, no surprise to anyone who’s tested alternatives, iSCSI and NFS also work pretty darn well! And you can knock that extra CPU load right down to the FC level with an iSCSI HBA.

Next up is a best practices paper from Network Appliance that is chock full of VMware storage goodness. If you’re curious about the potentials of NFS storage for VMDKs, this paper is a must-read! I’m pretty impressed with what VMware over NFS has to offer.

By the way, my next seminars are June 24 and 26 in Atlanta and San Francisco, respectively. I’ll also be presenting some related content at Storage Decisions in Chicago in May and Toronto in June.

Update:  Marc Farley talks back - isolate your networks, people!

ZFS really piques my interest, so I just had to include it in my TechTarget storage virtualization seminar series.

Here’s a quick primer for those of you who aren’t familiar with it, and thus are wondering why anyone would get stoked over a filesystem!

ZFS (originally “zettabyte file system” but now just ZFS) takes the essential technolgy from file systems and volume managers and stirs it together into one important new way to manage storage.  It’s an open source project started and managed by Sun, using the CDDL license (so Richard Stallman wouldn’t approve).  It’s loved by both Sun and Apple which makes it much more important.

See, ZFS will probably replace UFS (on Sun), HFS+ (on Mac), and every other file system and volume management product out there, especially on these platforms.  And I expect to see it appear on Linux once the tricky bits are resolved (which have to do with licensing not technology…)

ZFS creates a truly flexible, extensible, and full-featured pool of storage across systems and disks.  No more (of the old) arcane syntax, commands, ridiculous GUIs (ahem, Sun), and unnatural limitations of old system storage management.  With ZFS, you add some disks, get some space, and use it.  But it gets cooler than that…

ZFS “zpools” (file systems) live on “vdevs” with striping and optional RAID-Z/Z2 (which is double-parity kinda like RAID-6).  And, get this, every block is protected with checksums to ensure that the rapidly rising incidence of disk errors won’t bite you.  Want capacity?  128-bit addresses mean near-infinite space (in theory).  Oh, yeah, and all blocks are “copy-on-write” for snapshots and clones, something that barely works on most desktops and workstations.

But alas, there are some limitations…  Adding (and especially removing) vdevs is hard (read: maybe impossible) depending on how your storage was set up.  Stacked RAID is impossible, so no “Z+Z2″ for you!  And, until Sun integrates Lustre, there is no clustering support.

And then there’s the fact that Sun and Network Appliance are actively suinging each other over the fact that the technology in ZFS has ended up looking an awful lot like their bread and butter super file system, WAFL.

So there you have it.  If you’ll be in Washington DC on March 4, or Durham NC on March 6 and are interested in this topic, and the wider world of storage and server virtualization, I’d love for you to register and attend this free seminar!

When researching the interaction of storage and VMware for my upcoming TechTarget seminar series on storage virtualization, I picked up a few little tidbits of information that I wanted to share…

1. Beware of block sizes greater than 256 KB when using certain Fibre Channel arrays!  VMware’s performance research shows that throughput drops on some FC arrays, though they didn’t specify which ones…  Check out more performance suggestions on the VMware performance blog!
2. Align your virtual disk starting offset to your array.  A simple way to do this is to boot the VM and use diskpart, assuming you’re using Windows.  Misaligned disk offsets can double disk I/O, or halve performance, depending on how you look at it…
3. If you are using shared storage and want virtual disks greater than 256 GB, you must use a VMFS block size larger than 1 MB.  Or you could just use raw device mapping or NFS!
4. If using iSCSI or NFS, use a separate network or VLAN and consider an iSCSI HBA.  These cut down CPU load significantly in high-I/O situations.
5. De-duplication primary storage can have a huge impact on VMDKs created from a template!  See if your array supports this!
6. Thin provisioning can also be very useful in virtual machine storage, since a lot of VMDK space is empty…
7. Consider using NFS instead of FC/iSCSI with VMFS or RDM.  It’s pretty cool what modern NFS servers can do!  See NetApp’s Best Practices doc, for example.

If you’ll be in Washington DC on March 4, or Durham NC on March 6 and are interested in the world of storage and server virtualization, I’d love for you to register and attend this free seminar!

I’ve been feverishly preparing for my upcoming TechTarget seminar series focused on storage virtualization, so I thought it might be interesting to post a few topics from the talk here on the blog.  If you’ll be in Washington DC on March 4, or Durham NC on March 6 and are interested in the world of storage and server virtualization, I’d love for you to register and attend this free seminar!

I’m kicking off with one of my favorite topics, logical volume management on servers. This is the longest-standing and most-successful face of storage virtualization, and the one I was first exposed to. Put simply, volume managers abstract block storage (LUNs, disks, partitions, what have you) into virtual “volumes” for use by the server. They look the same to the OS, and still need a filesystem, but are much more flexible, as we’ll see.

Volume managers are very common today - all modern OSes (except for that one from Apple!) have volume managers built in. Windows has the Logical Disk Manager, which I’m told was co-engineered (or something) with Veritas way back when and which I’ve covered in my Storage Magazine columns. Linux has an implementation of LVM, which I wrote something about way back when, and which has now not been supplanted by EVMS as had once been supposed. AIX it’s own twist on the original LVM, as does HP-UX. Solaris has the variously-named Solstice DiskSuite/Volume Manager which has evolved substantially in the 15 or so years I’ve been using it. And everyone has Symantec’s Veritas Volume Manager/Foundation Suite, which we in “the biz” view with considerable admiration and some skepticism, as is the case with all good front runners!

Folks mostly use volume managers for flexibility. It’s really quite amazing what you can do when your servers run them, enough that you often wonder how you got along without them!

• You can resize volumes (aka file systems or drives) on the fly (if your file system supports this as most modern ones do)
• You can protect data with RAID, even if your storage doesn’t support it (think bare disk drives)
• You can add storage capacity on the fly by concatenating new to old or (maybe) expanding existing stripes and RAID sets
• You can mirror volumes, create snapshots, and even replicate data to remote locations (this functionality varies by product, of course)
• One of the most powerful things (to me) was the ability to migrate live volumes from one storage device to another when making infrastructure changes

In short, volume management = server-based storage virtualization! So even if you were skeptical about the claims about storage virtualization, you might already be using it! Amazingly, a good volume manager can do anything a storage virtualization appliance or enterprise storage array can do. In fact, some virtualization appliances have more than a little volume management source code in them…

And the only cost for all this great stuff is the impact on your server’s CPU, memory, bus, access control, etc…

The chart below compares the major volume managers, and includes a little easter egg at the bottom… But we’ll cover that on another day.

TechTarget recently announced a new Storage Decisions Seminar series focused on Storage Virtualization, with yours truly as the speaker!

Although the content is still being formalized, the first sessions are right around the corner on March 4 (in Wachington, DC), and March 6 (in Durham, NC). If you’re near either of these cities, I would love to have you attend and say hello! It’s a free day-long seminar with lots of technical and business content.

Further dates will follow in June, July, and later. I’ll be in London in November, too!

I’ll post more details as they become available!