Most companies need storage, have storage, manage storage, and hate storage. The biggest problem companies face is that across their servers, the average storage space utilization is 35-45%. If you map it out, some servers will use 80% of their disk, others will use 15%. So how can you allocate the surplus from one server to another server that desperately needs it?
If your servers have SCSI and/or RAID drives attached to them, then you have no ability to balance that allocation of disk space. The industry saw this fault, and came up with Storage Area Networks (SANs).
Initially, the term SAN was an overused buzzword, but gradually, the technology has evolved into a viable solution. SAN technology is about connecting your servers to a cabinet of hard drives over a high-speed link. Centralized management of the SAN allows you to allocate storage to servers on an as-needed basis. In your SAN cabinet, you can have anywhere from 10 to over 40 hard drives that can be configured for RAID 0, 1, 5, or 10. You can also mix and match RAID levels, depending on the requirements of each server or drive within a server.
This article will go through the components of a SAN, where it works best, and what you can look forward to in the future.
The Evolution
The first phase of SANs was direct attached storage (DAS). Servers requiring central storage and the ability to share and balance this storage were attached via fiber-optic cable to a cabinet loaded with hard drives. Fiber channel (FC) as a standard communication protocol was introduced here. While being a viable solution, it is limited to approximately four servers. Today, some vendors provide upgrade paths from DAS to a full-fledged SAN, which can get you started if you have a smaller budget and then grow with you as required.
The next step came as network switching became less expensive while providing more performance. This iteration was Network Attached Storage (NAS), which eliminated the four-server maximum. While cheaper than DAS, NAS has definite performance limitations inherent with Ethernet networks.
Adding to the network-induced performance hit was the fact that NAS is file-level I/O as opposed to the DAS and SAN block-level I/O. The difference is that block-level mimics the calls that SCSI makes, offering greater control and performance. File-level I/O is a higher-level interface that sacrifices control to accommodate open systems.
Enter SAN technology, with FC communications over a fiber switch. The switch provides the scalability of adding as many servers as you wish. The largest installation in Canada has 140 servers attached to multiple SAN cabinets. Switches start with eight ports and can scale exponentially from there. The latest version of the FC protocol allows 2 Gb of bandwidth, which most switch vendors are now supporting.
Components
The components of a SAN are similar to the components of a typical network. You have servers with Host Bus Adapters (HBA) that connect to a fiber switch, storage racks, and fiber-attached backup media. If you compare this to a network, you have PCs with network cards that attach to Ethernet hub/switch devices, which connect to a server with locally attached backup media.
At the core of the SAN is the storage, a cabinet that is loaded with up to 40 or more hard drives. The fact that there are individual hard drives is transparent to the servers that draw upon the storage. Multiple hard drives are configured to act as one, similar to a server with a hardware-based RAID card.
What's unique about SAN storage is that within a cabinet you can mix hard drive sizes and RAID levels, depending upon your needs. If you have a database server, you can take advantage of the added performance of RAID 1 or RAID 10. For typical file servers that do not need high performance I/O but would like redundancy, you can implement RAID 5.
On the SAN storage device, there is software that allows you to allocate hard drive space as a drive to a server or Logical Unit Number (LUN). Suppose you bring a new server into your environment. You want the system or C: drive to have RAID 1 mirroring. You also want a secondary drive that will store data and configure it as RAID 5, which is disk striping with parity. Using the software tools provided, you create these drives and assign them to the LUN assigned to the new server you brought in. A LUN uniquely identifies the devices that are on a SAN.
This software allows you to increase the size of a drive in a server when it is needed. It also notifies you when the increase is imminent. Windows 2000 servers support dynamic drives. When you increase the size of a drive for a server, the increase is seen right away. For non-dynamic drives or other operating systems, a reboot is required before the additional allocation is usable.
In this example, notice that all the drives required are actually in the SAN storage device. By implementing a SAN, you can purchase servers that have no physical storage attached to them! All storage resides on the SAN, which allows it to be expandable, allows you to create copies for offline backup, and allows you to buy 19-inch by 1 ¾-inch servers that start at $2,000.
There are many SAN storage vendors, ranging from XIOtech and EMC, as well as full hardware providers such as IBM, Compaq, and HP. Each of these vendors provides different benefits, but the majority of functionality you will use can be found in all these vendors.
Getting back to LUNs and how they fit into a SAN, LUNs are tied to an HBA card, which is installed in servers to draw storage from the SAN. The HBA emulates a SCSI card. If there is hard drive space allocated to the LUN associated with the HBA, then the server will think the drives are physically attached to the server. The server sees the drive(s) at the BIOS level, not through drivers or software in the operating system level. This is how you can purchase servers without any physical hard drives. The standard right now for HBAs is QLogic.
Connecting the SAN storage and the HBAs is the SAN fabric. This can be fiber or copper, but fiber provides better performance. In the near future, ratification of the 10 Gb Ethernet standard will allow more SAN installations to run over copper wires, but presently fiber is the best bet.
SAN switches are now supporting the FC 2 protocol, which provides 2 Gb of bandwidth. Switches are incredibly expensive, which makes SANs a bit hard to swallow. An eight-port SAN fiber switch can start at $12,000. The more ports you add, the more expensive it becomes. Two popular switch vendors are Brocade for the smaller installations and McData for larger installations.
Backing Up
Once you have everything tied together, it's critical that you are able to back up your data. As you can imagine, with all your storage requirements in one area, backups can be a large feat. However, DAS, NAS, and SANs provide some interesting technology to assist in backups.
Many vendors provide the ability to create a snapshot or copy of your data. This is exactly as it sounds, an exact replica of your data that sits in a different location in your SAN storage. Once the copy is created--which takes only a couple of minutes--you can back up the copy while your production environment is still running. This is a non-intrusive way of performing a backup.
Typical backup devices on a SAN are tape libraries using Advanced Intelligent Tape (AIT), Linear Tape-Open (LTO), or digital linear tape (DLT) as the tape media. These tapes currently have the highest capacity in the market--anywhere from 40-110 GB native and 80-220 GB compressed. Libraries allow you to run more than one tape at a time and to have several tapes waiting until the existing tape runs out of capacity. This allows you to back up more than a terabyte (TB) of data in one cycle. And because you are backing up the copy, you do not have to worry about a short backup window.
You can purchase tape libraries that are physically attached to the SAN fabric. In order for servers to use this type of configuration, the backup software you use must support SAN-attached backup media. Veritas' Backup Exec and Computer Associates' ArcServe both have the ability to use SAN-attached backup media. However, certain features--such as the ability to create a copy or snapshot before performing a backup--are not supported natively by the software. To automate this task, you must write a script or macro that will run prior to the backup starting.
Some SAN storage vendors are now offering their APIs to backup software vendors so that the advanced features are available in the backup software. You will soon see an option in Veritas' Backup Exec and Computer Associates' ArcServe that allows you to create a SAN storage copy of your drives and then back up that copy, all in one click of the mouse.
One other component of a SAN that you may see is a Gigabit Interface Converter (GBIC), which allows your fiber and gigabit Ethernet devices to communicate on the SAN. A GBIC will convert fiber communications to Ethernet--or the other way around if that is what you are looking for. Increasingly, you will see a wider selection of devices that can draw resources from your SAN.
My Fears Quelled
What about single point of failure? Having all my eggs in one basket? If I have all my storage in one area, with one path to it, what happens when it goes down? This is the question that SAN salespeople are asked the most. With good reason, as we have tried to attain centralized decentralization. We want centralized management but decentralized resources so that an outage on service A will not affect services B, C, and D.
If you review SAN hardware components, you will see that there is a single point of failure; however, the redundancy within the components is substantial. All power supplies, fans, hard drives, fiber cards, and in some cases processors, are hot swappable with spare failover units. For a component such as your SAN storage, you would have two cards capable of communicating with the SAN fabric. Both would be plugged in so that, if one fails, your servers will still be able to access data.
SANs offer a moderate risk to your data, but you are experiencing the same risk if you run only one iSeries 400. The box's reliability is the best in the business, and hardware failures are rare. But when they do happen, they substantially impact many different areas of the company.
Where It Makes Sense
I have touched on some of the benefits of a SAN; now, I'll discuss where a SAN makes the most sense, mostly derived from where the biggest ROI can be seen.
Common sense tells us that a small office with two servers does not need a SAN. Larger IT shops with more than 12 servers would benefit more from a SAN. At our location, we have 14 servers and will be phasing out five servers, as they are older and not needed. No matter how we look at it, a SAN is just not financially viable for us.
One of the best ways to justify a SAN is to consider how much you'll bring your server costs down by not having internal storage or backup hardware. You can now purchase a server for under $5,000. If you were to stagger the replacement of 12 servers over three years, you would replace four servers per year. At $5,000 per server instead of $30,000, you save $25,000 per server (or $100,000 per year). In two years, you can save $200,000, which is a good ROI.
Application service providers (ASPs) are ideal candidates for SANs. They have server rooms stocked with servers; in addition to needing storage, they need real estate. With a SAN, they save money on the purchase of each server, and they save space. Servers without hard drive space and backup hardware consume much less space than their larger counterparts.
ASPs must run 7x24. With a SAN, copy/snapshot features enable them to keep their servers up when backups are running. Furthermore, with copy/snapshot, a copy can be assigned to another server if a server completely fails. And when it's time to test new patches or upgrades for an application, the copy can be assigned to a different server, tested, and then brought into production if it works properly.
SAN technology may make it into our building when we replace our Manufacturing Resource Planning (MRP). We are looking at both iSeries 400 MRP vendors and Intel MRP vendors. A common misconception is that we could save quite a bit of money by buying Intel instead of iSeries. Not at all true. If you want the availability of the iSeries with Intel servers, then you should be spending the same amount of money. One way to accomplish this is with a SAN; cluster several servers in one and have a spare server standing by.
Here is how we have it planned. If our MRP is Intel-based, we purchase four servers for around $3,500 each. Three are configured as a server cluster and operate on the network as one server. The servers draw upon a SAN for their storage and backup requirements. If one server experiences a hardware problem, it is turned off. SAN storage space is unassociated with the LUN in the failed server. The storage space is then associated with the LUN in the spare server, the server is booted up, and the cluster of three is now operating at full capacity again. The entire operation should take approximately five minutes, during which time the cluster is still running.
We will also be heavily using the copy feature of the SAN during implementation and testing portions of the project. At the beginning of every day, a copy will be made of the MRP on the SAN. We'll proceed to make changes and then test the changes. If we realize a mistake we made corrupted the installation of the MRP, we'll shut down the server, disassociate the live storage space with the LUN of the implementation server, and associate the morning's copy with the server. Within about 15 minutes, we'll be able to continue with implementation. SAN companies say that this method can shorten your deployment time by about 30%.
Future Developments
The future of SAN is foggy and clear at the same time. The storage community is competitive, and vendors are adopting different standards. A shedding of companies needs to occur, and standards need to emerge as winners for true interoperability. At present, there are no clear leaders, which is slowing the adoption of the technology. And salesmen are using different terms for the same definitions, which confuses the end user and further hinders adoption.
Also, SANs will start to extend past the current 10 Kilometer limit through the use of iSCSI, FCIP , iFCP, or Infiniband. SAN islands will form in the larger companies with replication occurring to ensure complete availability and redundancy. If a SAN storage cabinet fails, there will be no interruption to business.
You should see 250 GB drives come out within the year. Larger drives will continue to be released, and tape media will lag behind. One tape can back up approximately 200 GB. With the release of 250-GB drives, a single hard drive is larger than a tape. So how do you back up a cabinet of 40 drives without using 40 tapes? The tape backup industry is going to be forced to come out with higher-capacity tapes. Look for the next generations of DLT, LTO, and AIT to support 200 GB natively and 400 GB compressed.
My prediction is that servers, switches, and SAN hardware will start to consolidate onto a single chassis. As you need a server, you purchase it and plug it into the chassis. If you need more ports in your SAN, you buy them and plug them into your chassis. You now need more ports on your Ethernet network, so you buy another slot and put it into your chassis. As your needs grow, you simply buy additional rack-mountable chassis and string fiber links as the interconnection.
Recap
As a technology, SAN serves a need--but at a substantial price. While duplicating certain aspects of your infrastructure (such as adding new switches), it does ease the management of storage. If you have more than 12 servers and you replace your servers every few years, you can build a good ROI plan that makes SAN technology financially viable. In addition to the hard costs savings, you can see savings in soft costs via high availability and a shortened implementation for certain projects that have their storage hosted on a SAN.
If any of these scenarios could serve your company, I recommend you take the moderate risk of placing all your eggs in one basket. The advantages your company experiences will make it all worthwhile.
For more information on SANs, visit the following Web sites:
Evaluator Group--Storage Consulting Company
The Storage Group--Storage Consulting Company
Fibre Channel Industry Organization--Standards Body
Chris Green is a Senior Network Support Specialist located in Toronto, Ontario, Canada. He has seven years experience focusing on the iSeries 400 and networking technologies. Utilizing this experience, he has authored over 30 articles and several white papers and has co-authored an IBM Redbook entitled Securing Your AS/400 from Harm on the Internet. For questions or comments, you can email him at
LATEST COMMENTS
MC Press Online