What you will learn from this tip: How to create a SAN architecture that leaves room for new technologies and shifting business priorities. Need a downloadable copy? Go here.
SAN design is a lot easier than it was a few years ago, thanks to new tools from vendors and more experienced storage administrators. But if you want your SAN to scale up as your enterprise grows, you'll need to think carefully about your choices during the planning phase.
Develop a SAN road map
Designing a scalable SAN starts with a vision of where you are going and when you expect to arrive at each point on your route. You'll need to examine your enterprise's overall growth plan and determine the storage needed to support it. How fast will your storage needs grow? Will you need to support remote sites? Will your organization have special needs, such as a sub-net on the SAN to support a long-running application without affecting performance?
One of the first points on the map is choosing the right-sized switches. Generally, a larger switch is cheaper on a per-port basis, while smaller switches give more flexibility in design and growth. A SAN designer should try to estimate the ideal port capacity increment based on projected growth and storage needs and choose switches accordingly.
Take a moment to look at your vendors' road maps as well. Are they moving in a direction that will support your vision of your future?
Invest in scalable management tools
SAN management may not influence performance all that much, but it has a huge effect on the SAN ROI because of the labor savings it can offer. (There's also the savings in wear and tear on SAN administrators' tempers that comes from working with tools that make it easy to do their jobs.)
Select your SAN management software with an eye for the future. Look for software that can support multiple vendors' products, that plays well with other software and uses industry standard interfaces and reporting.
A core/edge design, in which two or more directors/switches in a central layer connect to other switches that connect servers to storage, provides an extremely flexible design with a lot of growth potential. That doesn't mean you have to start with a core-edge design. A lot of SANs start off with a single switch handling a few servers and storage arrays.
Design for reuse
As your SAN grows you will probably outgrow the first switch or switches on your SAN -- at least as central switches. Likewise, as 2 Gbps Fibre Channel becomes standard and 4 Gbps Fibre Channel becomes available, you can move older, slower components to the edge of your SAN to handle storage with relatively modest performance needs. Plan how you will shift hardware to less demanding jobs as it is replaced with newer, faster equipment. Your routing algorithm should allow for links and switches with different speeds as well.
Minimize latency by minimizing hops
Each switch-to-switch transfer in your SAN's data path adds latency and cuts into performance. If you lay out your SAN so the storage and the server it supports are both on the same switch you avoid hops. As the enterprise grows this may require moving storage and applications among switches.
As much as possible, keep your options open
The world will change and you want your SAN to change with it. Assume that SAN speeds will increase, new technologies (such as iSCSI SANs) will continue to appear and that your organization's requirements will change. Try to make choices that will give you the options of more choices in the future. As much as possible, avoid locking yourself into one vendor's products or a single SAN philosophy.
For more information:
Tip: How to document a SAN
Tip: Keep your SANs from crashing
Tip: Troubleshooting your SAN (more or less) painlessly
About the author: Rick Cook has been writing about mass storage since the days when the term meant an 80 K floppy disk. The computers he learned on used ferrite cores and magnetic drums. For the last 20 years, he has been a freelance writer specializing in storage and other computer issues.
This was first published in December 2004