Musings on Storage

Read­ing Time: 3 min­utes

I know I haven’t exact­ly been fill­ing the blog-space with use­ful tid­bits, ran­dom ram­blings, or mus­ings on clown psy­chol­o­gy late­ly. To be fair, how­ev­er, I have been pret­ty heads-down in two dif­fer­ent areas: one on my CCIE Rout­ing and Switch­ing lab stud­ies; the oth­er on a large Flex­pod (UCS, NetApp, VMWare, Nexus) imple­men­ta­tion project at the office.

We are a long time VMware shop, and when I came on board back in 2006 I made a push for even more uti­liza­tion. We start­ed expand­ing heav­i­ly and made the choice at the time to use Equa­log­ic iSC­SI SANs for our back­end stor­age solu­tion. This worked well for a num­ber of years, but now that Dell has pur­chased Equa­log­ic we have seen our sup­port qual­i­ty slip­ping, res­o­lu­tion times stretch­ing, and parts deliv­er­ies slow­ing sig­nif­i­cant­ly. As such we moved to NetApp.

One of the things with NetApp that makes it an intrigu­ing solu­tion is the soft­ware, par­tic­u­lar­ly around cloning of vir­tu­al machines as well as snap­shots and de-dupli­ca­tion. While these are pow­er­ful tech­nolo­gies to be sure, some­times get­ting your head around the details can be tricky. Even trick­i­er? Mat­ing up what you thought you knew, or what you’ve grown used to, with the real­i­ty now.

What am I talk­ing about in par­tic­u­lar? Defrag­men­ta­tion and Microsoft.

Every­one who uses a SAN and VMware prob­a­bly knows by now that defrag­men­ta­tion, espe­cial­ly where VMDK files are con­cerned, is a giant waste of time. After all, you’re try­ing to move data blocks on a hard dri­ve around to make them more effi­cient, but those blocks are real­ly just rep­re­sen­ta­tions of blocks inside of a file, using blocks, on mul­ti­ple hard dri­ves. Sim­ple, right?

Well, with NetApp snap­shots the rea­sons for not defrag­ment­ing get even more ammu­ni­tion: you’ll actu­al­ly use more space. Why? Because the snap­shots are track­ing change blocks (deltas) and so don’t take up any space at all when first cre­at­ed (or very lit­tle) since you’re just dupli­cat­ing the root inode. Every time you defrag­ment, you’re poten­tial­ly rear­rang­ing all of the “blocks” of the file sys­tem, which is going to then trig­ger a big­ger delta come the next snap­shot. It’s the same rea­son why you some­times delete space on a vol­ume and don’t see it: the snap­shot has to grow by the same amount as the change, and since the snap­shots are on the same vol­ume as the data… well, there you go.

So, all of this is great. Don’t run defrag and life is good, right? Sure. But Microsoft is try­ing ever hard­er to be help­ful and they’re actu­al­ly cross­ing more and more into that ter­ri­to­ry occu­pied by Apple that I don’t care for: the one where they obscure all of the details to “just make it work” and you have to hunt to find even the most basic of fea­tures.

Turns out that in Win­dows 2008 and 2008 R2, defrag­men­ta­tion is set up as a sched­uled task by default. Every Wednes­day as a mat­ter of fact. The good news is that the task is dis­abled out of the box. The bad news? Most serv­er admins have an almost pavlov­ian need to defrag­ment Win­dows box­es and prob­a­bly have turned this (or some vari­a­tion) on for many machines in your envi­ron­ment. Pos­si­bly even through a GPO that some­one set and for­got many cycles ago.

At the end of the day, defrag­ment­ing a vir­tu­al­ized Win­dows box might make the OS think its hap­py, and it might even make the serv­er admins hap­py. Stor­age folks, how­ev­er? The shriek­ing from the unfash­ion­able wing of the IT area will prob­a­bly be all the indi­ca­tion you need that bad things are afoot. Hell, if you’re real­ly look­ing for some of the old ultra-vio­lence, run defrag on all your machines at night… at the same time. If you’re lucky, and every­one’s asleep, you might even man­age to offline a LUN. And that’s just good fun for every­one.