The Basics of SAN Implementation, Part II Page 3
Local mirroring via Fibre Channel Protocol (FCP) is always synchronous and supported for distances up to 500 meters over multimode fiber, or one or more storage systems may be located up to 10 kilometers from the SAN appliance if Fibre Channel switches with long-wave gigabit interface converters (GBICs) and single-mode fiber are used. Remote mirroring over an IP network supports either synchronous or asynchronous mirroring and can support distances greater than 10 kilometers.
Finally, let's look at why applications that depend on an ever-increasing amount of data are now seen as a strategic resource and, in some cases, a key source of revenue for organizations. In the past 11 years or so, there has been a virtual renaissance in the information and computing field--particularly around storage.
Implementing SANs for Database Applications
Gone are the days when only the most essential information was kept on computer storage or disk drives (DASD for those who have been around for awhile). This was due, in large part, to the high cost of storage and associated interfaces. Also gone, are the days of double digit dollar per megabyte costs, proprietary and expensive interfaces and costs associated with managing storage (well, almost).
Open systems and open interfaces including parallel SCSI and non-proprietary storage devices including parallel SCSI RAID, have helped drive storage prices down to the current range of well under a dollar per megabyte. Today, new requirements including disaster tolerance, extended distances, world-wide applications, along with content-based web applications and databases, have placed an emphasis on storage being scalable, modular, highly available, fast, open, and cost effective. While existing parallel SCSI storage and, in particular, RAID arrays, have gone a long way towards addressing these requirements. The storage industry is still limited to evolving towards the "virtual data center" vision or concept by storage interfaces and proprietary solutions.
New Storage Interfaces
The storage interface or "plumbing" that sits between the host computer systems and storage devices (like parallel SCSI) is now nearing or, in some cases, has become itself a hindrance to growth. That is not to say that open interfaces like parallel SCSI are dead or dying — far from that. Rather, a new storage interface is needed for new growth-oriented applications for high bandwidth distributed applications, and for applications that need large amounts of data moved to various systems. In fact, parallel SCSI will continue to co-exist in many environments and is part of an overall storage area network (SAN) storage implementation strategy.
You should keep in mind that the key to configuring storage for performance and database applications is to avoid contention or choke points. So, you should avoid the mistake of trying to use a single, fast, Fibre Channel interface or loop to support all the storage when implementing a SAN for database environments. Instead, to spread I/O devices such as RAID arrays on different interfaces to avoid contention, you should use multiple Fibre Channel host bus adapters along with existing parallel SCSI adapters.
For example, a "SAN Box" is the simplest and easiest way to implement a SAN and gain experience that can be used for implementing a full-blown SAN. A "SAN Box" is simply a small SAN made up of a host system with a Fibre Channel adapter, a storage device, and either copper or fiber optic cabling. The hardware components for a SAN include Fibre Channel host bus adapters, cabling (copper or optical), hubs or switches, and storage devices like RAID arrays. Device drivers for the host bus adapters, management software, and optional, special function host software, are software components you may need to include. Special function software includes host mirroring software for remote or disaster tolerant mirroring of storage, backup software to access SAN devices, data sharing or file replication software, clustering software, or distributed locking for messaging and database applications.
You might want to implement some small production SANs based upon hubs or switches that enable groups of systems to share storage and resources as a next step. A subsequent step would be to interconnect various sub-SANs and implement zoning or volume mapping to isolate storage to specific host systems for data integrity. Volume mapping enables a shared storage device, such as a LUN on a RAID array, to be mapped to a specific host system. In a shared storage environment, volume mapping ensures that only the authorized or mapped host can access the LUN.
Furthermore, for a different application or for performance reasons, you should consider implementing a second SAN that is isolated from the first SAN. Up to now, cost and availability has been the main advantage of using hubs for simple or small SANs. During 2003, you should expect to see a shift in the industry where more switches will be deployed to connect multiple sub-SANs together. Reduced cost per port of switches, increased functionality, management tools, and interoperability, is what will drive this shift towards an increase in switch use.
You may need more bandwidth than provided by a single loop or hub. Of course, this depends on the needs of your SAN. For increasing bandwidth in a SAN for host-to-SAN, within a SAN, and storage device-to-SAN connections, there exists a couple of methods. For example, additional host bus adapters may be added and attached to separate hubs, loops, or switch ports, to increase the bandwidth between a host and a SAN. Since there is still a single shared loop, by simply inter-connecting two or more hubs together without a switch, will not increase bandwidth. However, by interconnecting two hubs with a switch that will provide 100MB/second on each of the two hub loops (as well as, for each of the switch ports), performance can be increased. By using a switch to increase bandwidth between various points in the SAN, Inter-SAN performance can also be increased.