Jump to content

Boot from SAN - Brainstorm


ChrisBaksa

Recommended Posts

Hello all,

I am posed with a situation and was wondering if anyone has delt with this already.

I have been asked to do a build of Windows 2003 Server using EMC SAN Storage as the Boot Device.

At this time, I have all the drivers for Fiber Cards removed from my PE Build. I would have to put them back and I'm not too happy about that as it can be very dangerous and very unpredictable.

My biggest problem is that an Emulex (or Qlogic) cards default setting out of the box is Boot. And no one really bothers to change it. With that said, it's not the new installs I'm worried about.. it's the existing servers that could possibly be re-built or recovered.

Basically, if the fiber card driver is loaded, and the card is set to boot..... say bye bye to the data on the SAN even if that was not your intention.

So you see my dilemma, but now is the bigger question.... How do you address it?

My biggest concern is protecting existing data on the SAN.

Comments... Suggestions... Idea's

Chris

Link to comment
Share on other sites


I'm a little confused. You want to deploy this 2003 build to only new servers or do you want to be able to recover corrupt servers as well? Is your dilemma determining whether a logical drive is actually a SAN or is it whether a drive should be recovered period?

Link to comment
Share on other sites

I'm a bit confused too.

- You have a several existing Win2003 servers that boot from internal disk, but have data volumes on the SAN.

- You now have to build servers that boot from the SAN

- You're concern is that if one of the existing servers is rebuilt using your new build, it will go out and grab the data volumes on the SAN and format/install there?

Is that right or am I off base?

You can make partitioning the drive a manual step.

You could script a check in PE (you mentioned your using WinPE in this) that identifies the volumes as being either on the SAN or local, and if local doesn't load the drivers for the Emulex cards.

You could just make a step in the rebuild procedure be to unplug the fiber cables to any server with internal disk or the SAN admins disable the ports on thier switches until after the rebuild/recovery is complete.

You could also take inventory of the servers that fall into your risk group and reconfigure the Emulex cards to the proper configuration.

Personally, I'd be leaning towards these last two steps. I've worked with SAN attached and SAN boot Windows servers for years and I understand how quickly things can go very bad. If the prefered config for local boot servers is not the way the cards are currently configured, then you really should set them up the way that you feel they need to. You also need to address the procedure for configuring new cards so that if a card is replaced it's set up properly. If the data on the SAN is important (and it's always important) then physically seperating it from the rebuild either by unplugging or shutting off its ports is really the only way to be sure that you're not going to end up with an accident and massive restore on your hands.

Just my two cents.

Link to comment
Share on other sites

This is Difficult to explaine.

Currently, my Server build checks for a valid disk parition on the boot device (I don't deal in actually creating raid containers as there are way too may configurations, hardware models and vendors). In most instances that partition is found on the servers Local Raid Controller. But if the fiber drivers are on the PE disk and the fiber card is set to boot, the the disks on the SAN are seen as the boot device.

Now the complext part. All my current servers in production that are SAN connected but boot from the Raid Controller. Almost all have the default Fiber card setting of Boot. Since my PE cd does not have fiber drivers, it was never a problem. It cant see the SAN anyway.

Now I would be introducing the drivers back. If one of the existing servers needed to be rebuilt, the SAN data would be destroyed as the SAN would be seen as the 1st valid disk because the fiber card is set to boot.

So how do you overcome this? Thats my problem.

Link to comment
Share on other sites

Personally, I'd be leaning towards these last two steps. I've worked with SAN attached and SAN boot Windows servers for years and I understand how quickly things can go very bad. If the prefered config for local boot servers is not the way the cards are currently configured, then you really should set them up the way that you feel they need to. You also need to address the procedure for configuring new cards so that if a card is replaced it's set up properly. If the data on the SAN is important (and it's always important) then physically seperating it from the rebuild either by unplugging or shutting off its ports is really the only way to be sure that you're not going to end up with an accident and massive restore on your hands.

In a perfect world... a setup process wold be nice. But my issue is I must cover all angles and protect data at all costs. I can't rely on the SA's doing manual configs and a remediation project to correctly configure hundreds of servers globally would be a nightmare.

My goal was to pose this question and let people who have addressed this already comment. This way I can review the comments and engineer a solution into my environment. I only previously supported SAN after the OS was installed... so this is new unchartered territory for me. I have to proceed very cautiously.

Chris

Link to comment
Share on other sites

Two PE Builds? One with the drivers one without. The one with for building new machines after resetting the boot option on the card. the other for doing rebuilds?

I thought about that. Making that function would be the easiest. But I'd rather not gen a new version of PE.

It gets tedious when you have to manage multiple versions and keep up on driver changes/updates/additions.

I have 4 versions as it is (32 bit CD image, 32 bit PXE image , 64 Bit CD image, 64 bit PXE image)

Thanks for the suggestion.

Chris

Link to comment
Share on other sites

I have 4 versions as it is (32 bit CD image, 32 bit PXE image , 64 Bit CD image, 64 bit PXE image)

Chris, can you give me a quick answer as to why you need all four of these versions?

Link to comment
Share on other sites

Chris, can you give me a quick answer as to why you need all four of these versions?

32 Bit CD - Stand alone CD with tools/scripts/drivers/applications for 32 bit OS's (desktop and server)

64 Bit CD - Stand alone CD with tools/scripts/drivers/applications for 64 bit OS's (server) - Unattend 64 bit OS installs

32 Bit Image for PXE - Fully scripted (automated) image on the PXE server for 32 bit OS's - no user interaction at all.

64 Bit Image for PXE - Fully scripted (automated) image on the PXE Server for 64 bit OS's - no user interaction at all.

The PXE images are smaller. All tools are network based where as teh cd images have alot of tool on the cd.

Keep in mind that I don't do image building yet. And I cannot use any of the "Hacks" for installing a 64 it os form 32 bit PE. If it's not supported by Microsoft. I cant use it.

Chris

Link to comment
Share on other sites

I'm not very familiar with EMC but I do have experience with HP San. Sounds to me like the issue is a misconfigured SAN.

I would re-configure the san to show volumes to specific systems. I think this is called "Selective Presentation" Via the WWID, each data path to a disk should get a unique identifier. This allows dual redundancy. For windows os's, a required 'secure way' product was required on the server side. 'Secure way' ensured the server side 'pathing' information didn't step on itself. From the san side, it was done via the controller.

We had setup with 2 switches, dual HBA's in each host, and dual fibre controllers on the shelf, so disk actually had 8 data paths. By configuring the Controllers with selective presentation, we had several Microsoft Systems sharing the San with 6 Alpha OpenVMS systems. Some disks were presented to the MS Servers, and most the VMS systems.

This configuration allowed for life to continue if a switch failed, a controller failed, a fibre cable was damaged, etc. Dual redundancy all the way!

In summary, I would control what disks are presented to what systems. When needing to configure a new system, I would go to the san and 'present' the disk with your PE Images as well as the disk you want to install from. By the way - we indeed setup the both VMS and Windows servers to 'Boot' from the San. that was a previous life...

The Nets Edge

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...