Storage Management Strategies for the CIO
This article can also be found in the Premium Editorial Download "Storage magazine: Storage salary survey: Are you being paid enough?."
Download it now to read this article plus other related content.
Considering those benefits, as well as the management difficulties that existed before the advent of storage area networks, it would seem we all should start booting from the SAN. Instead, users are taking the tortoise approach to SAN-based system generation and the reasons are worth noting.
In IT shops with hundreds--and when you consider mirrors, thousands--of OS disks to manage, booting from the SAN must be a technological boon. To understand that, let's look at JumpStart from Sun Microsystems Inc. as an example of an application that can be enhanced to take advantage of having boot disks on the SAN. Keep in mind that any volume management or backup and recovery application could bring this functionality under its umbrella of services.
For large Solaris shops, system generation is likely to be aided by JumpStart even without a SAN. Profile configuration and rule files are created, configured and then applied to boot images before they are copied to the installing client over a local IP network. For all intents and purposes, this is managing storage on the front end with some performance and architectural
Requires Free Membership to View
(bootp) limits on the number of simultaneous clients that can be generated at once (see "SAN boot simplifies systems management" on this page).
Booting from the SAN doesn't replace products like JumpStart. Instead, it enables you to manage boot images on the SAN from the back end, which is less expensive and faster than using a JumpStart profile/boot server to initialize multiple Solaris systems over IP.
Just as today, where there's no dependency on the JumpStart server after the OS is installed, there wouldn't be any dependency on the JumpStart server in our proposed SAN-based solution either. After the OS image is generated and copied onto the selected target disks in the SAN, all ownership of the disks would be released, put into a default zone and then later reassigned to the incoming server's host bus adapter (HBA) when the system is connected to the SAN and its world wide name is discovered. From that point and until an OS upgrade or hardware replacement is required, the disk would be exclusively assigned to and managed by the incoming application server as if it were locally attached to the server.
Today, Solaris systems with internal boot disks may be taken out of their packaging and plugged into a locally broadcasted network where JumpStart is used to install a system image on its disks. Afterwards, the newly generated system is wheeled to a more permanent location in the rack and then connected to its storage devices over a SAN or direct-attached storage (DAS) connection.
However, when managing boot images from the SAN, newly unpackaged systems outfitted with only CPUs, NICs, memory and some number of HBAs can be taken directly to the rack, connected to the SAN and configured to boot from one of the free OS disks previously created with minimal ease. That makes the deployment of one or many servers more efficient and cost effective.
| SAN boot simplifies system management |
This was first published in December 2003
Join the conversationComment
Share
Comments
Results
Contribute to the conversation