Here is my summary of responses that I recieved for my question regarding booting from a SAN. I would like to thank all who responded. I would like to see a resonse from someone that has actually built an environment where the Solaris boxes boot from the EMC's. What interests me is the pitfalls of such an environment and whether or not they would do it again. EMC's stance is "it works GREAT....", yet it sounds more like a sales ploy to get a company to depend on the SAN for all things. My issues are the following: 1. I understand that in order to be able to boot from the SAN you need to have EMC's proprietary PROM installed. I prefer to leave the SUN PROM installed. 2. Isolating a problem may also be a problem because it may be hard to differentiate the problem from being host specific or SAN. My preference is to use SDS for the internal root disks and Veritas for the external disks. At any rate, below are the responses I recieved. Original Question: I am trying to get the pros and cons of booting a solaris box from an EMC vs. mirrored local disks. If anyone has any experience with the Solaris-EMC-Boot config and it's benefits and drawbacks. Responses: Kevin Buterbaugh: "I personally prefer booting from mirrored local disks. The reason is that any other configuration (EMC, A1000, etc.) all have some sort of "If such and such occurs, I can't boot my box." For example, while you can boot a Sun from an A1000, what if there's a problem with the RAID manager software? On the other hand, if I've got my root disk mirrored across controllers, almost all of that is eliminated. Hope this helps..." Don Harris: "I don't have experience booting from an EMC disk, but I don't boot any of my production servers from the disk boards. (They all have mirrored boot disks in a D1000). There are a couple reasons for doing this. 1. Disk boards take up another slot that I could be using for CPU/Memory or I/O boards. 2. If the server dies, I don't have many options for getting it back up and running, other than fixing the problem. All my production servers are config'd the same way, so I could just grab my boot disk tray (a D1000) and plug it in to another (staging/devel) server and let it boot the disk tray, and it would automagically become the first server that died (as it is booting the other set of disks now). Granted you could move disk boards around, achieving the same end effect, but this saves you from having to move the disk broards around. 3. Any mirroring you do on a disk board is done through software (either Disk Suite / Veritas). This takes cycles. If you use EMC you might be able to do something within EMC to mirror them outside of the o/s. (If you used something like an A1000 you use hardware based mirroring, so, it wouldn't put any more overhead on the o/s itself). The main advantage to doing this is that you can save 1 slot by not using disk boards. Seth Rothenberg: "There is EMC at our site, serving the mainframe, but we have not yet accepted the IBM team's offer to hook us up. Here's one thought that came to mind....it may be extreme, but something to think about.... One reason we bought Sun disk instead of connecting to the EMC was that EMC admitted that major firmware upgrades require the Storage to be down. I realized that this could still be 99.999 or higher, but the fact is, shutting down the system for regular maintenance should not be needed. What it means for you is, when that maintenance occurs, your host must be down. Not just your application. With the Sun A3500, we needed to replace a controller board (OK, that is a story of its own), and we did it online. I would have been very nervous upgrading the A3500 if we had booted from it (I don't even know if they allow it :-) We boot off local disks. My particular preference is, I am asking for two Multipacks on each system, each with multiple disks. The first disk on each multipack is root (root mirror on the second multipack); the other disk(s) are used for other admin activities....actually, we have done tests where we have used vxvm to sync local disk with the A3500, and then idled the A3500, all the while, running our live system. We then resynchronized A3500, and detached the local disk." Paul Timmins: "Well, I have some opinions here: - Con: Booting from the SAN is relatively new... I've seen problems in boot timing. I'd use it for several months in development before moving to production. Every environment has it's problems... - Pro: You can use EMC's timefinder (snapshots, or BCV's) to manage boot images.. - Note: Make sure you use volume logix for lun masking... also, make sure you have a system with local bootdisk, so you can boot it and run the volume logix software. - Con: May have some performance improvement by having your OS run off a different controller than the SAN... From experience, most people use local disks for boot. Booting from the SAN is often a pain... however if you have a very standardized environment, it may be reasonable to play with it in the lab and work out the kinks. The advantages to eliminating all local disks is very strong..." Brooke King: "Pro: You get another place from which to boot that is isolated from failures that can plague local disks. Con: You use up precious LUNs, which do have a rather low limit, in my opinion and compared to competitors, in your EMC Symmetrix. What we do: Conserve LUNs by only booting from locally mirrored disks under Veritas Volume Management. I automated the Sun Blueprint regarding best practices for managing boot disks with VxVM, well, at least the parts about mirroring, de-encapsulating, and re-initializing root. This has served us well when we JumpStarted many such systems and had to go back and add VxVM to others." -- Regards, Tom Zurita Sr. Site Engineer 24x7 ICCC: 888-898-7667 SiteSmith, Inc. Main: 703-467-5780 485 Spring Park Place, #1500 Fax: 703-467-5799 Herndon, VA, 20170 Direct: 703-796-3016 http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=Tom+Zurita+The+PonchReceived on Tue May 29 16:46:09 2001
This archive was generated by hypermail 2.1.8 : Wed Mar 23 2016 - 16:24:55 EDT