7.1 So Now We Have One

only for RuBoard - do not distribute or recompile

7.1 So Now We Have One; What Do We Do with It?

Isn t that the way it always is? Some new technology is developed that can potentially help your enterprise, and all of a sudden there are a myriad of questions that need to be answered .

• How can this new technology help my business?

• How can it be deployed in our environment?

• What software applications take advantage of this new technology?

These are just a few of the questions that are being asked about SANs right now. We probably won t answer all of these to your satisfaction here; however, by discussing a few known industry implementations it may help you focus on implementation in your environment.

Anytime these types of questions are asked, the answer invariably is, It depends. I say this because the first step in answering these questions is to know the variables in your own environment and where you are going in the future. Therefore your first two questions should be:

• Where s our enterprise now?

• What s our road map to the future?

Once you have answered these questions for your own operation or industry, then you can answer the questions regarding the new technology.

Now, having said all that, let s take a look at some of the ways Storage Area Networks can and are being used.

The SAN capabilities to be exploited are:

• Speed ”   How fast do you need to access your data?

• Distance ”   How far apart do your storage devices need to be from your computer systems?

• Continuous availability ”   Do your databases and applications need to be online 24/7?

• Sharing ”   Do different servers need to share data or devices?

7.1.1 Speed

We have discussed in previous chapters the I/O transfer protocols, such as SCSI. We have explained that Fibre Channel is much faster in transferring I/O than these other protocols. Therefore, if accessing data really fast is a requirement in your environment, then a Fibre Channel SAN is your answer.

Remember, Fibre Channel currently runs at 1 Gbps; the ANSI standard for Fibre Channel defines a theoretical speed of up to 4 Gbps. So Fibre Channel is fast, and will get faster. Of course, speeds will depend greatly on the design of the components connected within the topology and the specific function for which they are connected.

7.1.2 Distance

If extending the distance between devices is an issue in your environment, then a Fibre Channel SAN can possibly be your answer. Cascaded hubs and switches can increase distances between the servers and the devices being used in the SAN.

For example, if you have a server in one building and the database for that server resides on a storage device in another building, then a SAN may be the right answer for this application. Even if the storage device is a SCSI device, it can still be part of the SAN by using a SCSI bridge to connect it to the SAN.

7.1.3 Availability

Continuous availability or high availability is vital for some applications. E-business and automated teller machines don t shut down at 5:00 P.M., so there s no such thing as doing hardware maintenance on the night shift. High availability storage subsystems use redundant components and RAID hardware or software. These devices can be rather expensive, but in some environments they are absolutely necessary because data must always be accessible. High availability requirements continually create a higher demand for SAN functionality, mainly because it s easy to scale the SAN with more and more high availability storage.

7.1.4 Sharing

One of the primary drivers for SAN adoption is the concept of sharing data or devices. Sharing reduces the need to have two or more of any one thing, such as a database or the storage system it runs on.

For example, a company may need to provide its customer database to many different internal divisions and regional sales offices. This requires duplication not only of the database, but distribution of the duplicate data to duplicate hardware at the remote sites. Of course there s a constant need for resynchronization of centralized and distributed data as the customer records change.

Another area of sharing is the hardware ”the storage device itself and the server using the device. Some companies purchase their hardware from only one vendor for a given application. For example, they would purchase an NT server and an associated storage device from the same vendor. Then for another application, say in a UNIX environment, they would purchase a UNIX server and associated storage device from another vendor.

In this scenario, you wouldn t want to have to buy different storage devices for different servers. What that amounts to is wasted money, floor space, and so on. Heterogeneous SANs can and do address issues like this.

• Sharing a tape device.   A tape library is expensive and need not be used exclusively by one server. It usually contains more than one tape drive and many tape cartridge slots. Multiple servers can access the different tape drives at the same time to accomplish their read/write operations.

• Sharing different disks in the same device.   Using certain disk array configuration tools in conjunction with SAN management tools, the disks within a disk array can be divided for use among different applications or servers.

• Sharing the same data between servers or applications.   The Holy Grail of sharing. This is when two servers have a need to access the same data. Then it s great if they can both read and write to the same LUN.

only for RuBoard - do not distribute or recompile