Sailing the Storage Area Network Islands - dummies

Sailing the Storage Area Network Islands

Imagine that you’ve grown to love this storage area network (SAN) stuff so much that it’s reproducing itself like rabbits throughout your company! Things are starting to get out of hand again. You have little islands of SANs located in multiple buildings, and you’re finding it hard to manage all those separate SAN environments.

A new trend in SAN management is the capability to access and control a company’s storage resources from a centralized help desk using a single management console. Another trend in storage networking is the capability to replicate data between locations to enable disaster recovery. What makes all this possible is the ability to connect SANs.

However, having SANs in multiple places is a good thing, and you can take advantage of that fact by using the locations as backup or recovery sites for your company. You can actually make the gloom-and-doom disaster recovery folks happy.

Defining a SAN island

A SAN island is a storage area network that’s physically isolated in a single location and is managed as a separate physical entity, as shown in Figure 1.

Figure 1: SAN islands are separate entities.

Like a local area network (LAN) using Internet Protocol (IP), a SAN island consists of all the servers, switches, and storage that are physically connected in one location. Some SAN islands are isolated within the same building on different floors or in different departments. Each small SAN might currently be used for different applications or perhaps be used by separate business units within a company. (See such a configuration in Figure 2.)

Figure 2: Individual SAN islands dedicated to different application environments.

For example, your mainframe computer might be hooked up to its own dedicated SAN storage network, and your UNIX and NT servers might be connected to another storage network. You might even have two separate Information Technology (IT) organizations involved because some people are “mainframe” people and some people are “server” people.

Traditionally, many large companies had multiple lines of business, with each business unit in charge of its own independent IT departments. These departments would act independently of one another. Each business unit could have its own technology budget, with each one doing its own thing.

The problems with this approach have become apparent during the latest downturn in the economy. Companies have found that having separate IT departments causes duplication of personnel, expenditures, and infrastructure, and hampers the ability to leverage the integrated buying power of each business unit. This wastes a lot of money. Consolidation is the fix, and companies are now in the process of implementing consolidated environments. Companies are consolidating their IT budgets and leveraging their buying power. In doing so, companies are finding that they can consolidate their storage environments, which enables them to create disaster-tolerant infrastructures for the company.

If you’ve heard the terms server consolidation, data consolidation, and restructuring, they all mean about the same thing: Do more with less.

Connecting SAN Islands

Individual smaller SANs are connected to form a larger SAN to share and copy data:

  • Disk/data sharing: The need to share disks among servers in different SANs is brought about by applications such as e-mail, application clustering, and access to information in large databases. Data sharing can be accomplished by enabling access from multiple servers to the same physical disks, or by enabling access to the files located on those physical disks. Sharing physical disks needs to be done through a SAN, and sharing files can be done over a LAN.
  • Data copying: The need to keep data safe and recoverable in the event of a disaster is one of the main driving forces behind a company implementing a SAN. The data located at one location can be very easily copied to a second physical location over the storage network. Backing up your data to a remote location enables you to get access to that data in the event of a disaster at the primary location.

Disk/data sharing

Sometimes, different departments within the same company are somewhat autonomous, including different budgets and buying habits — with no storage vendor standards in place. One of the disadvantages of letting folks do their own thing is this lack of standards. For example, a company could have a number of small SAN islands in place, consisting of different types of servers and storage from many vendors.

The servers might be connected to a low-cost departmental storage array in a small SAN in one department, and another department might have an expensive high-end array because it has a larger budget. This business would run a lot more efficiently if it could share storage arrays and allow data access from all the departments by connecting those departments into a larger, consolidated SAN.

Take a college campus as an example. Servers connected to separate SAN islands located in different buildings on campus might need access to the same data for sharing research information. You need a way to connect those buildings so that all the servers in every building can see the same storage. Connecting everything, in effect, creates a pool of storage resources that can be accessed by any server connected to the pool.

The need for disk sharing can also be driven by the need to create server clusters. A server cluster is a method of tying together two or more individual physical servers to look like a single logical server. If one of the servers has a problem, another one takes over for the failed server. To create a hardware cluster, each server needs access to the same physical disks. The members of a server cluster can be located in different buildings by using a SAN to connect to disks over long distances.

Data copying

The need to copy data stems from many origins. Maybe you need a copy of a production database to use for testing live data for a new version of an application. You might have developers located in another country who need a recent copy of data for testing. You might also want to keep a recent copy of your critical data on disk to recover corrupted files.

The main reason for keeping copies of data is for recoverability. Many companies currently back up their data to tape and ship it off-site just for this reason. The downside to using tapes is the need to restore data back to disk before it can be used again. Recovering data from tapes takes time, and time is not a luxury that many companies have these days.

This is where SAN-based storage replication comes in. All the critical data that’s housed in the storage arrays in a SAN can be copied in real time from a main production facility to a remote storage array located in another building, state, or country. Having the ability to copy critical data to a remote disk in real time — versus recovery from a tape backup — means that you can recover from a disaster in minutes instead of hours or days.