Coming to you from the mind of Neil Glick (The Brain), a good old fashion, home cooked technical blog regarding storage, virtualization, and anything else that crosses my mind.
All Opinions Are My Own.
If you want to reach me on Twitter, I'm @meneilg

Wednesday, February 26, 2014

We were busy last week. We created Podcast 13 and had a live Brain & Wendel show. For podcast 13 we had a special guest star, our good friend from Cisco, Mike Brennan! Mike is a Technical Marketing Manager for Desktop Virtualization Solutions at Cisco and a really great guy. Hear Mike talk about what's going on at Cisco and what's we can expect!

I've put out some blogs before about properly sizing your desktops and how important it is to get actual numbers from your customers, BUT you need to be able to trust those numbers. So what the heck am I talking about? One reason I've seen many VDI implementations fail is the unwillingness to change how the desktops operate. Let me explain.... Show of hands, how many people still have a physical desktop and the day you have a virus scan run you either:

Sure you can try and slog your way through the pain and be productive during this time, but it is painful and it feels the more you fight it, the longer the scan takes. Plus, now that hard drives are larger than ever before, virus scans take that much more time.

This is what I mean by changing how desktops operate. These outlying events REALLY tweak your sizing numbers and to size your VDI environment to absorb these events would have you buy an enormous amount of hardware that would cost you a fortune!

One of the key reasons VDI hasn't taken off is cost and there are multiple reasons that I won't go into right now, but I do want to discuss the affects of these outlying events. They will skew your numbers and will push your implementation to a whole new level of cost to absorb events that might happen 2-3% of the time. Virus scans, OS patches, just to name a couple.

So am I saying ignore those outlying events and size for a smaller environment? No, what I'm saying is for VDI to be cost affective AND functionally affective we need to change the way we think. Virus scanning and OS patches are administrative functions that can't be ignored, but this is the perfect time to be creative and look for alternative methods to solve the problem.

A friend of mine once told me there's always a bottleneck and during an assessment you want to make sure your product is not the bottleneck. In VDI implementations these events are certainly the bottlenecks and we want to shift them so the users don't have to suffer through them AND help limit the expense of the project. Luckily there are some great products out there to do this and I'll cover some of them later, but I wanted to write this first article to get you thinking that you need to question the numbers! If they don't look right, heck, even if they look right, question your customer's and find out what's happening in their environment. They'll thank you for it! :-)

Here are a couple of examples for you.

These are Performance Monitor outputs from my computer. The first is me just doing regular work, I've got email open, a ton of internet browsers open, I've got YouTube running and you can see that the writes are higher then the reads. The writes are really low, so I'm only running about 10 IOPs total.

This next graph is still my computer, but with a virus scanner scanning my hard drive. You can see the reads are just going nuts! I'm still doing my other work like before, but my desktop is just getting hammered by 176 read IOPs and 15 write IOPs with a total of 191 IOPs!

Yes I know this is something that probably only runs once a week and yes I know using a mean calculation would flatten out this peak over time, BUT my point is these types of events will severely impact your results. Even if the peak flattens out to 76 IOPs per desktop, that's going to be a VERY expensive desktop when 99% of the time the IOPs are only running around 10.

If you've assessed the environment and have performance numbers I'm proud of you! But we have to go to the next step to make sure we know what's going on in the environment. This way we don't charge the customer for a sports car when all they really need is a nice 4 door sedan. :-)

Wednesday, February 5, 2014

Today I'm going to continue my Nimble Scale-Out introduction and talk to you today about pools.

Nope, not this kind of pool Mom. My Mother loves pools and keeps telling me I need one. Well Nimble Pools aren't concrete bowls with tile and plaster, and they require a whole lot less chlorine!

Over the last few days I talked about what groups are and joining groups. So back to my example, if the group is the gated community with all of the amenities, then pools are the social activities all the residents are part of. You just moved into the Las Casas Caras gated community and your next door neighbor Chip finds out you're a golfer! The two of you hop into his hybrid and go play 18 holes!

What the heck does any of this have to do with Scale-Out?! It will all become clear momentarily... Chad's your other neighbor, he's a nice guy but doesn't like golf. So let's examine the scenario I've painted below. Chad is on the left. He's not part of the golf club, so he's in Pool 1. Notice the bubble over his head? Since he's not part of the club he's not sharing his thoughts and ideas with anyone. Now take a look at Pool 2. There's you and Chip and you're giving each other a high 5 because you just got an eagle on the 14th hole that was rated a par 7. Not bad!! Notice the bubble above your and Chip's head? Well you two are sharing information about the course, your jobs, how Brad's dog keeps pooping all over the neighborhood, etc. This is now shared information between the two of you.

In a nut shell, that's Pools! Instead of Chad, Chip and you, there are arrays and the conversations are volumes that data stripes and balances to each array in the pool.

Say you and Chip have a falling out about hybrid vs. all electric vehicles and you no longer want to go golfing with him. You can leave the pool, but you'll have to transfer all the information you know about golfing, and Brad's pooping dog over to Chip before you can leave. Make sure Chip's brain can hold that extra amount of data cause if it doesn't, you can't leave! Once you leave there will be 3 pools unless you decide to join Chad in the fishing club. Similar to groups, you can have a maximum of 4 pools.

I'll probably write another blog with screen shots from the GUI later.

Monday, February 3, 2014

Okay, okay, all of these Part #, Part # are probably really annoying, but I realized after reading my blog that I left some things out that I really wanted to tell you about regarding groups. So instead of trying to tack on extra stuff to the original article, yada, yada, yada, you get it.

If you didn't notice there's a lot of cool new stuff to 2.x, but there are some caveats to be aware of. Nothing Earth shattering, but stuff I feel you should be armed with before you jump head first into the deep end of 2.x.

Okay, so let's quickly go over the benefits of 2.x.

1. 4 array GUI's in 1. (Ease of administration!)
2. Add new arrays to the group as you purchase new hardware.
3. Remove old hardware with no downtime as they retire.

So somethings to watch out for when going to 2.x.
1. Networking. Yep, we covered this in the previous blog post.
2. Volumes. Source groups vs. Destination groups.
3. DR and replication.

Let's talk about 2. The Source group is the group or array that's going to merge into the Destination group. We covered this a little bit, that the Source will lose most of it's identity, when it joins the Destination. Now if this is a new array, NO problem, but what if it's an existing array with volumes and data being served? If it has data and volumes, those volumes have to be temporarily taken offline while the array/Source joins the Destination. Not a huge issue, but something to keep in mind if your Source already has data on it.

How about 3. Similar to number 2, replication needs to be paused during the merge. But something more to think about is if you happen to be replicating between the Source array and Destination array, that won't work anymore with arrays in the same group. Again, not Earth shattering, but something to keep in mind if you're implementing this at your site.

Now what happens if you realize the gated community is just not for you? The neighborhood kids pee in the pool and the rules are too strict. Can you pick up your array and leave? You sure can! Again there are caveats and you'll need to migrate shared volumes, snapshots, clones, etc. But, all joking aside this is a VERY cool feature when you've got an older array in your group that you're looking to either retire or turn into a DR array.