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

Friday, June 28, 2013

I've started to use a Cisco UCS for compute and while it is a VERY cool platform it's like I'm having to re-learn what it means to administer servers. When I first started using it I thought, "Who was the crazy person who came up with this?!", but the more I use it the more I'm really starting to like the flexibility it gives you!

This is going to be a REALLY entry 101, more like a 1, but I felt as I learn the UCS more I'd continue blogging about it. My UCS is currently being used, so I won't be able to show you everything, but I'll do my best to explain.

Once you're inside UCS Manager you'll see a bunch of tabs in the upper left hand corner. Click on the Equipment tab.

Here you'll see all of the hardware currently being administered by your fabric interconnects. Now here's where things get a little different. I thought, "Cool, just highlight one of these servers and I can pop in a CD or direct it to an ISO image." Well, it doesn't quite work that way. Click on one of your servers and take a look at the right hand of the screen.

Holy Macaroni! When I first saw this I was majorly overwhelmed and this is just the Equipment tab! Let's break it down to the basics.

1. Associate Service Profile. Sorry, mine is grayed out cause it already has one, but if you have hardware that's either new or not in use it probably won't be grayed out.

2. Service Profile. I'll go into this a bit more in a minute.

3. KVM Console. Awwwww, finally something I understand! This will give you console access to your machine. If you don't have a service profile attached, this will be grayed out for you. HUH? So how the heck do I log onto this thing to install ESXi, Windows, Linux or whatever?!

4. Configured Boot Order. This is very handy. This tells the equipment how you'd like to boot it. So here my first boot device would be a CD-ROM, and then iSCSI. If you have local disks in your system you can boot from local disk, or SAN, or whatever! The UCS is super flexible this way. Remember if you don't have a service profile attached, this won't be there.

So now that we have a bit of information about the server itself, what the heck is a service profile and what does it have to do with anything? The way you give a personality to individual blades is by creating a service profile. Think of it this way. The equipment is the android body. It has all of the capability to walk and talk, but without a brain or connections to that brain it's just a lifeless shell. Think of the service profile as all of the connections from the brain to the body. Here you create the mapping of connections, network, storage, etc. Once you have it all mapped out, you assign it to one of the blades. So remember arrow number 2 in the image above? Let's click on the Servers tab and then click on policy ESX5.1-3.

Take a look at the left hand side. You can create all of the service profiles you want, they don't have to map one to one with a piece of hardware. You can see a bunch of service profiles that have been created. When I click on ESX5.1-3, I get a ton of information about the profile. If I click on the Boot Order tab I can see how this profile will boot. If you take a look this profile will first boot off the CD-ROM and then iSCSI disks, but that is completely up to you when you're building the profile. The neat thing is you can map an ISO image to the CD-ROM, so you don't have to use physical media.

The great thing about this is you can create a bunch of profiles, associate them to iSCSI LUNs, a blade and install whatever OS you want on that LUN. Next you can disassociate that profile move it around to other blades or just have it ready when you want to use that OS. So for example, you create 3 profiles: Windows 2008R2, ESXi 5.1, Linux. I can associate or dissociate at will, which makes this SUPER cool in a testing environment.

So that's my Cisco UCS 101 for now. There are a TON of things you can do here and I've barely scratched the surface, so be on the look out for a lot more UCS blogs.

Tuesday, June 25, 2013

A collegue of mine gave me a great idea to follow up my Replication Made Easy with Nimble Storage blog with a planning replication using Nimble InfoSight. (Thanks Rick!)

Setting up replication is just part of the equation, but probably a more difficult question is, how much bandwidth do you need? You know pipes aren't cheap! There's a really cool feature built into InfoSight that helps with data protection planning. WHAT?! You're still not using InfoSight? Okay, here's the link again... InfoSight

Hey, I'm just trying to make your life easier here! :-) Once you get your account, log in and you'll see a plethora of data! I'll follow this blog up with others regarding the coolness of InfoSight, but today I'm focusing on replication.

Click on the Data Protection tab. Here you'll see all kinds of great
metrics regarding your replication, but for today, click on the Planning
tab.

Where was this when I was setting up replication as a system administrator?!! Let's go through each number here.

1. The average weekly change rate. This information is AWESOME! Back when I was doing this, we had to make an educated guess. Too much bandwidth and we'd being be paying too much, too little and replication would be horribly slow and you might not even meet your SLAs.

2 -7 allows you to drill further down into the Mbps and get REALLY specific on what is changing.

2. Allows you to choose what the replication role is. Do you want to see source, target, or take out unreplicated data.

3. If you have volume collections, you can add or remove them from here.

4. Volumes themselves can be added or removed. Remember, not everything needs replicating, it will depend heavily on the application and how your disaster recover program is set up.

5. The performance policies can be chosen. Say you want to see how much data is changing in your Linux environment, but not with Exchange.

6. With approximate interval you can further zoom in on what kind of times you want. Does the data only change seldom or all the time?

7. And finally the array. If you have a dev/test array and aren't replicating it, you can deselect, etc.

When I saw this functionality I said, "Wow!" Honestly, this really helps take out the guess work; saving you time AND money.

Friday, June 21, 2013

I’m referring to Nimble’s Cache Accelerated Sequential Layout. If storage was a burger, CASL would be the secret
sauce!It looks like Thousand Island
dressing, but man it’s NOT Thousand Island dressing!

In today’s market everyone is SSD happy.I’m waiting to hear SSD’s cured world hunger
and war!Don’t get me wrong SSD’s are
cool, but I don’t think they are the panacea everyone has labeled them to
be.If I were an SSD I’d be STRESSED
with all the pressure people put on me!They’re
expensive, they have a finite life, and oh did I mention they’re expensive?

If you have more money to spend then you know what to do
with, well then I guess you should just buy what you want!And if you have that much money, you should
retire and go have fun, what are you doing working?!Anyway, I digress…If you’re like the rest of us, on a budget,
and you’re looking for the best solution for the money, how about a hybrid
option?

Nimble Storage has done something very clever; they’ve taken
spinning media and complemented it with SSD’s giving a killer synergistic
effect. It’s really quite cool. Nimble coalesces random or sequential inbound data blocks
and writes them sequentially to the
spinning disks to optimize write time while compressing the data at the same time to save space. Nimble doesn’t
over write an existing changed block, which speeds up write time since that
block is marked for cleanup at a later time. While the coalesced sequential writes are happening
a cleanup or sweep is running
in other parts of the disk to cleanup those old blocks.

Think of it as a conveyor belt moving
around.As old blocks are cleaned up,
disk space moves back to the front of the line waiting for more new
blocks.In the middle we have stored
data that can be at rest, but at any moment can be retrieved for a user
request.

So what about reads?When they’re accessed from disk, they’re put into cache so the next time
a request for those blocks is called upon they’re don’t have to come from
spinning media.Giving smoking fast
response time.

Wednesday, June 19, 2013

Today I'm going to show you how easy it is to replicate your volumes/data/virtual machines on ESXi, etc. with Nimble Storage, with the added bonus of compression and snapshots too!

1. First we'll need to create a replication schedule and if you've been reading my blog you'll remember we did that in a previous article when I was showing you how to create a volume. If you don't create a replication schedule right when you're creating your volume, never fear, you can always select your volume and click on Edit at any time.

2. When your replication has run you'll see the replication status on the Volume information page will show you when the last replica was taken.

3. If you want more information about the replication, click on the Replication tab at the top of the page.

4. Let's jump over to the array that received the volume and take a look under volumes. Here I've already clicked on the replicated volume. Down in the lower left corner you can see here that the replication partner is the array I first showed you. In the upper right hand corner notice that the status is Offline and a replica.

Okay, great so what now? Well, you've now got replication from Point A to Point B that is on a schedule and will continue to update itself. The nice thing is the compression you were getting at Point A is sent over to Point B just as it is, so no re-compression needed. You can do a bunch of things now. You can either claim this replica and bring it online, but if you do that, you'll break your replication. What I prefer is to clone off the replica and work on that image.

6. Click on the Snapshot tab in the upper right hand corner and then click Clone.

7. Give the clone a name and you're done!

8. Go back to your Volumes page and you should see the replica and your new volume. Notice the new volume is not using any space! Pretty cool huh?

From here what you do with this data is really going to depend on what application you're using. Is this a database, application, virtual environment, etc. etc. etc.? Disaster Recovery is a science all in it's own. But since I've got an ESXi environment handy, how about I bring this clone into my vCenter environment?

9. So first we need to bring the new volume online and edit it.

10. We add an initiator group to this new volume and you can protect it too if you want.

11. I've gone to my vCenter environment and scanned for new storage and then selected to add new storage. Notice the name of IQN.

12. This next step is a really nice feature in VMware. One of the biggest problems with copying volumes is the identification remains the same. It's like cloning a person, how do you tell who's who? VMware has a nice feature that assigns a new signature so you can mount both volumes up at the same time. This is only a problem for me because I'm using the same vCenter. If you were replicating between vCenters, you wouldn't have this problem.

13. Finish up adding your storage and then you should see a variation of your volume mounted up now.

14. Now if I right click on the datastore, I can browse it and mount up any virtual machines that live in there.

15. Here I'm adding my replica machine to the inventory and giving it a new name.

As I mentioned earlier, you really wouldn't do a replication and mount up the image in the same vCenter. If you wanted to do that you can use one of the snapshots on the local array instead, but I wanted to show you how easy it is to replicate from one Nimble array to another since replication in the past was not an easy thing to do.

Tuesday, June 11, 2013

It's been a fun couple of days. I've been trying to get vCenter 5.1 with the Single Sign On to install with MS SQL. I have to say, it's certainly a bit more challenging! I'd like to share some of the gotchas with you so if you're stuck or to avoid the problems completely.

First of all before you start the install there are five MS SQL scripts located on the install media located under:

Single Sign On > DBScripts > SSOServer > schema > mssql

Let's focus on two of the five:

rsaIMSLiteMSSQLSetupTablespaces.sql
rsaIMSLiteMSSQLSetupUsers.sql

The first creates the new database and the second creates the users. You'll need to change some of the path information, passwords, etc. So open them up in MS SQL and make the changes before you run them.

After the scripts ran I thought, "I'm good to go!" I started the install, chose Use an existing supported database and filled in the information. The users and database are created by the scripts you ran earlier.

Unfortunately I kept getting this error:

I checked the error log and kept getting a failed to establish connection error!

Thursday, June 6, 2013

I ran into a nasty error the other day that I'd like to share with you. So a little background. I was creating a Citrix PVS golden image and everything seemed to be working great. I'm running ESXi 5.0 with PVS 6.1 and XenDesktop 5.6. I took the default E1000 network card when I was building my golden image and boot times were horribly slow. I remembered I had some issues with the E1000 settings in the past, but I can hardly remember what I had for breakfast yesterday... I looked around and found this article on the Citrix site http://support.citrix.com/article/CTX131993 that says to use the VMXNet3 NIC. No problem, add a new VMXNet3 NIC in vCenter and delete the old E1000 NIC.

I switched my golden image from hard disk boot to vdisk boot, it booted MUCH faster and everything seemed to be working great. I put my vdisk into Standard Image mode and tried to boot up my PVS clones. Oh NO, not the BLUE SCREEN of DEATH!

Thanks goodness for Google! I started searching and found this article written by Jan Hendriks
http://jhmeier.de/2013/02/19/citrix-pvs-6-1-target-device-fails-to-start-on-vmware-esxi-5-1-with-a-blue-screen/ which totally saved me! It describes the error I was seeing and pointed to this Citrix article http://support.citrix.com/article/CTX125361, which pointed to these Microsoft articles http://support.microsoft.com/kb/2344941 and/or http://support.microsoft.com/kb/2550978. I guess when I replaced my E1000 for the VMXNet3 I introduced this. Luckily there was a hotfix available!

Monday, June 3, 2013

Last week I showed you how easily it was to configure the Nimble array, create volumes and bring them into VMware vCenter. Well what if you're a Virtualization Administrator and don't have access to the storage or just want an easier way to create datastores without having to create igroups or enter in IQN's, etc.? Today I'm going to show you how easy it is to do this with the Nimble Storage Plugin within VMware vCenter. So how do you get this cool feature to work? Read on!

1. Installation. Sorry, it's already installed! The only thing you need to do is go to the Nimble Storage GUI and enter in the credentials for the vCenter Host. Granted if you're a vCenter Administrator and don't have access to the array you'll need to have the Storage Administrator do this for you, or open the page for you. Click on Administration and go to Plugins.

2. Enter in the vCenter Host name or IP address, username and password. Click on the Register button and you're done on the storage side! You don't have to create igroups or enter IQNs to create datastores.

**Note** With all good things there's always the opposite side of the coin. If you do create datastores this way, they will be wide open because there will be no ACLs. If you want to control access, have the Storage Administrator go into the Nimble GUI and create the ACLs for you.

3. Head over to vCenter, click on your datacenter and you should see a new tab with the name of your Nimble array. Click on that tab and click on New Datastore.

4. Give your new datastore a name and a description if you'd like.

5. Select which hosts will have access to this new datastore. Here I only have one ESXi host, so it will be the only host accessing the new datastore.

6. Enter the size of the new datastore, the VMFS block size and if you'd like to use default space settings for reserves, quotas and warnings. These will vary on your environment, so choose what makes best sense for you.

7. Here you can create a protection policy for the new datastore and set up synchronization with vCenter if you'd like to quiesce the virtual machines during snapshots. If you don't want to set this up, click on the Delete button.

8. Here the delete button has been used. This step will also vary greatly for your environment. It's always best practice to backup your datastores unless the data is not needed.

9. Review the summary and when you're happy click Finish.

10. You're all done! The datastore is now being created and vCenter will let you know when the creation is complete.

11. Here we can see the datastore has been created and some metrics regarding it can be seen.

12. Click on the ESXi host(s) you set up to see the datastore, click on the Configuration tab and the Storage link. You should see your new datastore and it is ready to be used!