50Micron.com

Ok, I’m curious as to whether anyone has an answer for this.

Why don’t more people boot VMWare ESX from the SAN?

It occurred to me the other night that I have 2 36G drives in each of my servers that I use possibly 10G of, when I already have a High-Availability storage solution at my fingertips.  I’ve got plenty of storage space, not even including the vault drives.

So I tried it.  I took one of my off-line VMware boxes. (I use DPM so at any given time 2 of my 3 VMWare hosts are probably in StandBy mode) and popped the drives out of it.

I turned it on, went into the BIOS and disabled the onboard RAID controller and enabled the boot BIOS on one of the Emulex HBA.s

I created an 18G lun on the clariion and assigned it to the host as LUN0 and poof, I have a boot disk.

Worked like a charm.  The one surprise (pleasant) is that VMWare seems aware of the multi-pathed boot device even without any form of powerpath on the system.  (That was my biggest concern)

So now I have my VMWare infrastructure running on a host with ZERO fixed-disk drives spinning in it.

So has anyone else tried this and know of any gotchas involved that I may not have run across yet?  I’ve done windows and Linux native boot-from-san many many times, but this is my first attempt at VMWare.

I’ve not however tried pulling a path to see just HOW resilient it is…I should probably should try that before I convert the other two systems to diskless operation, right?

I’m bored – bygones.

Monday was another one of those days.  When will facilities people get it through their heads that

…maybe it isn’t a GREAT idea to test the generator during the day…

…maybe it’s something better done at night, on a weekend, or when the moon isn’t full…

…maybe it’s a good idea to let the IT people know you’re testing it…

…maybe it’s an even better idea to CLOSE THE BYPASS BREAKER before you start the test.

Monday at about 2pm the planets aligned in their universal task of making me work late.

17 hours later I left the site.

I’m pretty impressed.  We went from a quick-quiet datacenter to back up and running in about 10 hours.  A few more hours working out parts replacements… and all is golden.

Not bad.  Could have been better.  I hope so because in order to fix the Generator/UPS problem that caused the issue in the first place, they are going to have to take the power down again…

At least this time it will be graceful…I hope…I think they’ve scheduled it for the next full moon.

I will say this – of the vendors EMC was first on scene, and they had parts in tow before we even knew what we needed.

I’m suitably impressed.

I got the following storage request today.

“This host <hostname> is ready.  It will need storage.”

Dontcha love it?  My response was equally brilliant.

“Shall I just make up a number?”

(Somtimes I can be a jerk….)

Ok – certain people do certain things well.

I’m a storage administrator/architect.  If you present me a problem I will *ALWAYS* look at it from a storage standpoint.  If you present me with a non-storage problem, I’ll try and make it fit.

I’ve identified four types of systems engineer-type-people:

Storage people

Server people

Network people

Desktop people

I think that just about anyone in IT either fits into one of those four roles or supports one of those roles.

Now when you are looking to solve a problem, the solution you get depends on who you go to.  If you ask a desktop person to solve a network problem for instance, they will probably come up with something under the desk.  (IE throwing a linksys router under a desk.)

If you try and throw a server person a storage role, you’re going to get a server solution to that role.

Enter IBM GPFS.

GPFS is a server solution to a storage problem.  It’s obvious that the person who came up with the idea of solving a storage problem by loading software on a server is not a storage person.

POSIT:  Mutliple hosts in a web-farm need access to data.  Filesystems need to be R/W to an ingest server and R/O to the web-content servers.

Storage Solution:  NAS/NFS – Trunked connection to a real backbone and multiple Apache webserver front-ends running at 1G to play out data.  (Fastest data transfer is going to be the 45MB/Sec backbone coming into the building, so a single Gigabit connection can handle it.   F5 Round-robin load-balancer to distribute the front-end load.  (might also be proposed by Savvy network people, who tend to understand NAS)

Server Solution:  IBM GPFS solution.  Over a million dollars in net-new server hardware + software licensing (not including storage).   Each host accessing storage requires HBA’s, Drivers, fast RELIABLE network. and a level of complexity unheard of even in government.

From what I can tell, and maybe someone can give me a little more insight, works very much like Sun’s Shared QFS.  A metadata server acts as a gatekeeper telling which member servers can access which blocks on which disks.  There is still no simultaneous disk access because a SCSI lock is a SCSI lock.

Now from a storage standpoint, this is rife with problems.

First off, it would seem that if network access was compromised during a write data integrity could easily be compromised.

Secondly, Other than block-level mirroring of the underlying disks, I can’t see a good way to replicate this.  And block-level mirroring of the underlying disks would require an identical infrastructure at the remote/DR site wouldn’t it?  That is of course assuming that the metadata can be mirrored.

Now in database uses or other types of distributed computing I can see it being VERY valuable.  But for flat file storage and web retrieval I can’t think of a single good reason to use something so obnoxiously complicated.  Especially when EMC Celerra, NetApp, or just about any of the other higher-end NAS appliances would cost *SO MUCH* less and be *SO MUCH* more reliable.

/EndOfRant