Migrating Solaris to a Storage Area Network

Greg Schuweiler

Figure 1 | Figure 2 | Figure 3 | Figure 4

I work on a team of three UNIX systems administrators in a premier medical clinic, hospital, and research institute located in the Midwest. We were looking for a better way to manage our growing storage requirements than continually requesting money from management for drives "for yet another machine". Our environment consists of Solaris, HP, AIX, Linux, and a SCO box or two. For this reason, we wanted a "general" solution to our storage situation. We don't manage workstations, and most of the servers are used as database servers, mainly Sybase, a few Oracle installations, and an un-substantiated rumor of a big Informix database moving over from VMS.

We decided to start with a subset of our Solaris boxes for two reasons. First, the HP/9000s were running on a proprietary Fibre Channel arbitrated loop and as solid as a rock. And second, it was much easier getting down time on the smaller Solaris servers.

Before I discuss this any further I will define what we think a Storage Area Network (SAN) is and what it should provide. The best definition for a SAN is a pool of storage that many servers can access. Figure 1 depicts a simple SAN. I left out the switches, hubs, redundancy, and multiple paths for clarity. Ideally, any vendor's server could be connected into an existing or new SAN and play nice with the others. The server being added would not scribble on on LUNs that it did not own. With this type of configuration, I can put all newly purchased storage into this pool allocating the new storage as needed to each server.