|only for RuBoard - do not distribute or recompile|
A SAN is not difficult to configure and implement. However, managing and maintaining a SAN can be a challenge, primarily because of growth and complexity.
As the number of devices on the SAN grows linearly, the number of potential interactions increases . This is a good thing for bringing storage to servers and clients , but it could create management headaches .
The most successful SAN implementation will reflect planning, good management, and a sense of the cost/value proposition the SAN offers.
If you are thinking of implementing a SAN, you ll find that the planning is your first ally. There is a lot of order at the heart of the SAN, and if you plan carefully , you ll be able to buy, implement, and manage SAN equipment with fewer problems.
If you work in a chaos-driven topsy-turvy shop, as many of us have, the conversion to a SAN gives you a chance to imprint some order on a somewhat out-of-control storage topology. Your SCSI arrangement may have gotten a little out of hand, and with the SAN, you ll be off to a fresh start.
A planning document is the blueprint for SAN success. At its most complex, it can show every device and device address. At the very least, it demonstrates to management your plan for an orderly implementation. Whether you create a one-page or 100-page document as a blueprint for your SAN, create something. Ask yourself (and answer) the following questions:
Current configuration. What equipment do I have now? How much legacy equipment can I work into a new SAN?
Current needs. What s working well in my current configuration? What are the performance and connectivity shortfalls in the current implementation?
Future needs. What are my expansion plans for servers, storage, wide area interconnections, etc?
Rate of storage growth. How fast is storage growing now? When will I run out? At what rate in the future will I be scaling up storage?
Budget. What does new equipment cost? What does it get me? Can I justify this to management?
Topology. What will the new SAN look like? Where will I locate the equipment? What about cabling runs?
Management. How will I monitor and manage my SAN? How will I tune performance?
Intangibles. Will I be able to do more with greater ease? Will I be able to manage storage with fewer worries?
A good SAN plan can get your implementation started. It s also easier to expand a well-planned SAN. If you can, keep your SAN plan up to date.
A SAN is easier to maintain and manage than a SCSI storage configuration. Certainly , when equipment is stable and performing as expected, there is very little to manage.
SAN maintenance is primarily hardware maintenance. The device is either broken or it s not. However, with the SAN, you have enough failure-proofing to eliminate many downtime headaches while locating broken equipment.
HP has a set of tools for monitoring the status of the SAN. They are essentially device management tools, intended to check specifically if an HBA, a hub, a switch or a bridge is performing.
At a minimum, management tools should allow you to:
Monitor the overall status of all supported devices on the Storage Area Network
Monitor the operational status of each supported device (fans, power supply, and temperature)
Determine which switch, hub, and bridge ports are in use
Bypass and enable switch and hub ports
View switch information, such as: topology, status errors, statistics and performance
HP s SAN Manager Device Manager (DM) and SAN Manager Lun Manager (LM) are comprehensive SAN management packages. SAN Manager DM focuses on device management. SAN Manager LM is an efficient way to manage, assign and secure storage resources.
Performance management is also important. After spending money and time to put together a SAN, the last thing you want to hear is that the network runs slow. Fortunately, performance tuning software is getting better. If you happen to buy an XP256, there is the optional software package, Performance Manager XP, which allows for easy performance measurement and easy parameter changes.
Marketing literature from hardware manufacturers consistently cites a lower Total Cost of Ownership (TCO) as a SAN selling point. However, the mathematics of TCO is never spelled out.
It is expected that the cost of buying relatively expensive new equipment is mitigated by reduced maintenance costs and some measurable performance boosts. Unfortunately, the device is usually not shipped with a cost accountant in the accessory box to help you calculate the TCO.
Here are some of the SAN TCO factors.
Old cable runs will save money. If you have FDDI 62.5 micron cable in place, you can use it to connect shortwave hubs without recabling. This can save some money.
New cable runs will cost money. However, fiber optic cable is relatively cheap, and the increased distances permitted by Fibre Channel make it easier to plan cable runs. The labor to pull cable is not cheap; however, fiber is relatively easy to route and there may be cabling jobs in the data center you can do without hiring outside vendors .
No more SCSI cables. You won t need to buy more of those fat, costly cables. That s money back into the budget.
Hubs, switches, and bridges will cost money. Yes, but the hubs are a relatively low-cost item, and you can get a lot of mileage out of them. However, be prepared to buy switches, as the switched fabric has connectivity and performance advantages you will need in the future.
Legacy SCSI storage devices will save money. There s tread life left on those SCSI JBODs ”those you bought last year and those you bought last week. For the price of an FC4/2 bridge, they can join the SAN. You ll have to determine how long you might be able to use them before you abandon them in favor of Fibre Channel-enabled storage devices.
Fibre Channel storage devices will cost money. You ll have to check each product individually, but generally when you look at the capabilities of a Fibre Channel storage device, there s a good value proposition. The capacities are high, with a generally good GB/dollar ratio. Expandability and reliability are worth something, too. For many installations, they are worth a lot.
Intangibles have value, although they are sometimes difficult to measure. For example, in selling a business, good will is an intangible, yet the seller of a business must assign a monetary value to it. With a SAN, there are intangible cost factors, as well.
What is the worth of satisfied users, satisfied customers, satisfied management? In particular, technology that satisfies customers enhances the enterprise. As a personal matter, IT management s satisfaction with storage management will certainly be important to you during your annual review.
And what s the worth of your worrying less and feeling better about storage problems? A SAN will lower the Total Cost of Frustration (TCF) and the Total Cost of Headaches (TCH).
Distance runs get easier. That SCSI distance limitation, across the room or across the campus, is eliminated. SCSI cabling, with a nominal maximum length of 25 meters (or 75 meters with a booster/expander), cannot compete . This is even more true if you consider the TCF of handling thick SCSI cable.
Intrarack cabling gets easier. If you ve ever tried to populate a 2.0 meter rack with 16 dual-ported SCSI JBODs installed back-to-back, you know what we mean. The cabling is impossible . Fibre Channel is much easier and this saves on your labor, CE labor, and TCF/TCH.
HBA maintenance gets easier. A Fibre Channel HBA GBIC is a Customer Replaceable Unit (CRU) in some devices. There s a labor, time, and frustration savings here.
Scaling gets easier. That SAN planning you did will pay off when you scale up the SAN. You ll essentially just plug a new device into a hub or switch, and there you are! Of course, there s a little more to it than that, but it s relatively easy. And you re not just installing one device for one server. You ve added a device to the SAN that s potentially available to all devices on the SAN.
Backups get harder. Since storage is easy to add, you will add it. New storage capacity always makes backups longer (and of course slower). However, there are some great workarounds. These are discussed in Chapter 6.
Management and maintenance get easier. Hard to believe, but you will be able to manage more devices with less effort without getting out of your chair . Of course, there will be times when you ll have to go to the back of a server to look at the Fault LED on an HBA, but you ll get your first indication of trouble at your workstation.
Reliability pays off. Inevitably, there will be broken equipment, but with the SAN you should see few broken paths. The enterprise saves valuable time and money, because the impact of a down system is largely eliminated. This should save you any headaches created by working through crises .
|only for RuBoard - do not distribute or recompile|