Some of the technology involved in
building a SAN is complex. How has technology evolved to
make it a more viable and cost effective solution for
There are more management tools coming out and I think over time the industry is beginning to understand more and more of what people want. This market is almost, by necessity, a technology driven industry and as the market becomes more familiar with the technology, it is feasible to get feedback from people on what they want and I think that is what you?re starting to see. I think the biggest change is the emergence of management tools that make it easier. What's the first question a user should ask the vendor when building a SAN?
I think the first question should be along the lines of compatibility and interoperability. Not so much broad-based, but just drive toward trying to understand which solutions are out there. Then, understanding what the applicability is of those solutions towards the different systems that are running. And again, then you get to the applications on those systems. So, ask things like, 'Does the SAN solution map to my systems and does it map to my applications?' What's the number one reason businesses want to build a SAN?
The main reason businesses want to build a SAN is for data availability. The SAN architecture removes the single server system as a bottleneck or point of failure. The
NAS appliances are complete solutions and they also provide availability for multiple machines and there are already a lot of management tools built into some of the NAS products out there. There is simplicity in the low-end products that are just plug and play and a lot of management power in the high-end products. How can I justify the cost of building a SAN to my CFO?
Know what the costs are and see if you can project them. But I think where you want to look is at the business interruption potential that you might have or lack of availability. Also the ability to upgrade systems and storage separately means you have far less down time, planning, purchasing and reacting to emergencies than you used to do working in a SCSI environment. The real justification is in the administration time spent responding to problems. It means you can have a smoother operation and there are many benefits to that. What's the first question I need to ask myself before building a SAN?
You need to ask, 'How do I get the resources to make it work? Where do the resources come from? Do I get them internally, or do I expect to get them from vendors or independent consultants?' What is the biggest mistake users make when building a SAN?
That's a good question. I'm not sure what the biggest mistake is, but I think most users are going about it in a pretty prudent way: they are going slow, trying to understand what is there. I'm not aware of what I would consider a lot of mistakes being made and frankly people can't afford to make mistakes. I don't think there's a problem with solving people's mistakes. I think people are being very careful. How long can I expect the process to take from research to implementation?
A year to 15 months.
Live on-line event: Requirement for path control in large storage networks
What's the smartest move you ever saw or
heard a business do when it was building a SAN?
I think a lot of people do this: setting up a practice SAN and testing it. It takes a lot of testing. The implementation plan should probably have three months of internal testing before going live. Just be very conservative in the roll out of it. What don't I want to hear from a vendor, when building a SAN?
I'm not sure that I have answer for that but probably it would be that they are introducing a product in a few months. You don't want to hear about products that are not on the market. It's interesting because you do want to know about those products but you can't plan an installation on a product that doesn't exist yet. I think you should go with tried and true products that are on the market. Start there, but don't leave your installation waiting for a product to be delivered.