| QUESTION & ANSWER |
SD2002: Experts offer dos and don'ts on networked storage |
 |
By Michele Hope, Senior Site Editor
18 Jul 2002 | SearchStorage |
|
|
What are the biggest "gotchas" to avoid when implementing a storage area network (SAN)? How do you best handle vendors who come calling at your door with all promises under the proverbial SAN? SearchStorage asked these questions and more to our resident Storage Networking experts, Christopher Poelker and independent author Marc Farley. Also chiming in with key insights for this exchange is Dragon Slayer Consulting's Founder Marc Staimer, a frequent site contributor and upcoming speaker at Storage Decisions 2002.
After reading these answers, if you'd like to learn more about this topic, check out the following related events:
- July 25, 2002: Live expert Webcast with Chris Poelker, "Building high performance SAN/NAS infrastructures," Thursday, July 25, 1:00 pm EDT (17:00 GMT). Click here for details.
- August 22, 2002: Live expert Webcast with Marc Farley on addressing specific SAN management issues. Go to our Online Events page for further details as the date approaches.
- September 17-19, 2002: Special, in-person Storage Decisions conference session with Marc Staimer, "Get the 'value propositions' of emerging storage architectures." (Note: Attendance at this Chicago event is limited to only prequalified attendees. Register today to see if you qualify.)
What are the top 1-2 items most storage managers forget to do when it comes to deciding on a new SAN architecture in their organization?
Poelker: One of the most common things I see is the lack of planning in choosing an overriding framework for managing the SAN solution, from the application on down to the disk. Most storage vendors have very good element management included their solution. Most customers have been short-sighted in how to manage the switches, cables, HBAs, and path from the top down.
New framework software is now becoming able to handle these tasks. Vendors like HDS, HP/Compaq, SUN, and EMC are bringing out software that operates at a higher level than just element management. Third-party software developers now have software that will manage "multi-vendor" environments. Vendors like Qlogic are making available free APIs for managing their hardware, and the BlueFin initiative is taking care of the rest with standards-based development of management software. End users should start to take advantage of all this hard work.
Staimer: 1. Talking to the users and determining their availability requirements. It is usually assumed.
2. Putting together a long-range proactive plan/architecture that makes growth simple and easy.
Farley: How many SANs they may want to have. The idea that a single, large SAN that always grows may not be best. Also, they could look at having multiple autonomous regions in their SANs.
For department-level needs, are SANs a good bet? Or, is a NAS architecture more appropriate? What types of criteria should managers use in determining which architecture -- NAS, SAN or a hybrid SAN/NAS combination -- to begin researching for the needs of their organization?
Poelker: It depends on the application. Fast databases need SAN. File/Print works fine on NAS. Infrastructure servers like Domain controllers, DHCP servers, Web servers, etc., can even get away with internal disks. The business needs to weigh the unique benefits that SAN or NAS brings, look at the budget, and use what's appropriate.
Staimer: Typically, a hybrid NAS/SAN is the best overall solution for the department because not all applications work with NAS (MS Exchange, homegrown applications, non-standard database management systems, old applications). A hybrid allows the ease of use of NAS with a SAN block storage option for those apps that do not work with NAS, and it's only one system to manage.
Farley: I'd say for most department-level applications, where there might not be IT support as readily available, NAS is better.
When it comes to SAN implementation details for a robust data center, what are a few of the 'gotchas' it's best to work out ahead of time?
Staimer: 1.Identifying those applications that cannot handle disruptions.
2. Identifying the methodology required to minimize or eliminate "Registered State Change Notifications" to HBAs.
3. Determining the validity of the claims of various SAN vendors before the equipment is installed.
Poelker: Choosing the correct switch vendor for the job, and standardizing on that platform. Choosing the HBA vendor according to what works best for the platform, and standardizing. HBA driver versions are a big "gotcha". You need the right one that works and is certified for the OS, server, switch, and storage vendor.
If integrating different storage arrays from different vendors, then zoning should be used. Cable management and error detection is sometimes an after-thought, and kinked or improperly routed cables can cause intermittent problems. Staff training is a must, not only for the storage, but also for the switches and any unique vendor software or firmware involved. A good change control practice should be put in place to manage the SAN. Last but not least, the TEAM who is going to take all responsibility for the SAN needs to be put in place beforehand.
Farley: Path redundancy. Multiple paths from systems to storage need to be completely unique with no common failure points.
| | | | Get the [SAN] team in place. You need network, operations, server management, DBAs, etc. all involved, so the best choice is made for the business. --Chris Poelker | | | |
Let's say I'm making the move in the next 18 months from direct-attached storage to some form of a storage area network and this is my first foray into SAN territory. Any recommendations on how best to separate fact from fiction in various vendor claims and pitches?
Poelker: Step 1, about 18 months out, is to get the team in place. The team needs to come from all areas of the IT department, since putting a SAN in place effectively makes servers a peripheral to the data involved. You need network, operations, server management, DBAs, etc. all involved, so they can be initiated together as a team and all learn together, so the best choice is made for the business.
In order to weed out the sales pitch from reality, the solution must be tested in a real-world environment. Gather the info from the vendors, get pricing, and select one or two vendors that match your needs and budget. About two months out from final purchase, do an evaluation of the equipment to make sure everything that was promised actually works. Bring the entire team in for the eval., so they can all learn the ins and outs of each vendor's solution, and therefore can better judge which fits the business needs the best.
During the eval.:
* Test your applications for performance
* Test all the firmware functionality of the storage array
* Get to know how to operate the SAN switches
* Test your backup strategy with the SAN, etc, etc.
In other words, doing a "try and buy" is one method to make sure you're not left "holding the bag," so to speak.
Farley: Don't expect performance gains. Don't expect seamless scalability (you need a file system that supports it). Do expect easier management. Make sure you understand how the management system works in detail and don't be satisfied with a future story. You need to get ROI quickly. For newcomers, I'd say to get started with a LAN-free backup SAN first to get used to the technology in a less-disruptive manner. Then, move to disk attachment and storage pooling.
Staimer: Get references for 3 to 5 similar installations of similar local environments. Visit them if possible and minimally find out everything they went through with their experience and what they should have done to do it better. Find out which of the vendor claims were not quite true. Get all vendor promises in writing. Write a contract that penalizes the vendor financially for misrepresentations.
|
|
|
|
