SAN and virtualization disadvantages?

TeeJayHoward

Limpness Supreme
2FA
Joined
Feb 8, 2005
Messages
13,404
My school recently switched from a 42U rack full of Dell servers to a single 7U blade chassis, a 3U SAN, and a 1U switch. It's the first I've heard of businesses using "virtualization" to simplify their network. Apparently, they're running VMWare and 40-someodd instances of Server 2K3. The specs they told me were incredible...

Now on to my questions.

1) Theoretically, the throughput of a SAN should be significantly higher than that of a locally attached disk, right? How much higher?

2) Is there a latency hit associated with using a SAN as your only hard disk?

3) Is it likely that my school WAS using a SAN as their only disk? There were two little laptop-drive-sized hot-swap bays in each blade. Would they be using these instead? Why or why not?

4) Is VMWare an OS now, or were they running it on top of linux/server2k3/etc?

5) Does the chassis have some sort of OS associated with it? Or are they using one of the cores on one of the blades to run VMWare?

6) Any nifty links to read up on?
 
I am not all that familiar with SAN's by any means so take my answers as you will.

1) There is nothing I can think of on a SAN that will make it any faster than local disk assuming that the disks, controllers, and cache sizes are identical. SAN's usually do have very fast throughput in comparison to local disk but that is usually because the SANs have more disks or better controllers. On the flip side, SAN throughput can also limited by your interface whether that be iSCSI or Fiber Channel.

2) I would imagine that with Fiber Channel there would be very little latency increase, if any. With ISCSI there is likely a little extra latency added but I don't think it's enough to have a significant performance impact.

3)While you can actually boot off a SAN with the right controllers I would imagine that they may be booting each blade off the mirrored laptop drive set and using the SAN to store their virtual servers. That is how I would set it up anyways.

4) VMWare ESX server is in fact it's own OS (custom Linux I think) and has been that way for some time. They do have other products like VMWare Server though that run on top of a host OS like Linux/Windows.

5) I would imagine that each blade is running it's own copy of VMWare ESX but I am not familiar enough with blades to really guess on how they have things configured.

6) You could check out VMWare's website which has enough documentation to keep you busy for a long time. I am particularly fond of their forum too.
 
VMWare ESX is not really it's own OS. It's built on Redhat. Highly customized, but still not it's "own" OS.
 
1) Theoretically, the throughput of a SAN should be significantly higher than that of a locally attached disk, right? How much higher?
It depends. The SAN disks are probably Fiber Channel or at least SCSI, there's probably a few of them (15 or so in 3u, unless they're using 2.5" disks). Compared to a single disk, yes, they'll be faster.
2) Is there a latency hit associated with using a SAN as your only hard disk?
Yes. Is it noticeable? That depends ;)
3) Is it likely that my school WAS using a SAN as their only disk? There were two little laptop-drive-sized hot-swap bays in each blade. Would they be using these instead? Why or why not?
I'd guess those are just for swap. Could be they're booting the blades individually... but I don't think so. They generally boot from a shared root filesystem.
4) Is VMWare an OS now, or were they running it on top of linux/server2k3/etc?
You can install ESX on bare metal. ISTR they've written their own kernel; they're just using some of Redhat's userspace stuff.
5) Does the chassis have some sort of OS associated with it? Or are they using one of the cores on one of the blades to run VMWare?
They're probably each running their own copy of ESX. I wouldn't guess it looks like one big SMP machine, so each node would need to have its own OS code running - but who knows.

What're they doing with the old stuff?
 
What're they doing with the old stuff?
They mumbled something about "Legacy" blah blah. It's all still up and running. I'd guess it's an out-of-production environment to test updates before deployment, but I'm not certain.
 
Back
Top