Book Excerpt: Building SANs with Brocade Fabric Switches Page 10

---

By Josh Judd, Chris Beauchamp, Alex Neefus and Benjamin F. Kuo

---

Summary

The SAN design process consists of seven phases, which are cycled through as needed throughout the life of your SAN. Data collection and analysis together define the requirements of your SAN. These requirements feed into the architecture development process to produce a SAN design blueprint. After you have a plan in place for your SAN, you must test certain components to ensure that it is working the way you thought it would, before you can begin to transition and release it into production. Once the SAN has entered production, it falls into an ongoing maintenance phase, and continues in that phase until a change occurs that causes the cycle to repeat.

The first two phases (data collection and analysis) are critical to the health of the SAN. Simply put, if the information on which the design is based is incomplete and/or inaccurate, the design will be incorrect.

Data collection consists of a series of interviews, collecting the answers into a meaningful format (a technical requirements document), and verifying the accuracy of the collected data. It is imperative that all key stakeholders in the SAN project be included on the interview list.

While listed as a separate phase, data analysis actually coincides with data collection. The objective of the analysis phase is to turn the raw data, which is generally in the form of business requirements, into a more technical formatthe technical requirements document. Some of this occurs "on the fly" during the interview process. However, certain tasks are done after the interviews are complete. For example, detailed port count and performance requirements are generated "on the fly," and an ROI proposition is created after the fact. Once the requirements of the SAN are well defined, the remaining phases can take place. These phases are covered in subsequent chapters.

Solutions Fast Track

Looking at the Overall Lifecycle of a SAN

q       The SAN design process is a cycle.

q       This process consists of seven phases:

1. Data Collection

2. Data Analysis

3. Architecture Development

4. Prototype and Test

5. Transition

6. Release to Production

7. Maintenance

q       Whenever there is a fundamental change to the SAN, the cycle should repeat.

Conducting Data Collection

q       Data collection is the foundation on which a SAN is built.

q       You should interview everybody who has an interest in the project.

q       During the interview process, create a technical requirements document.

Analyzing the Collected Data

q       There are several things that you need to get out of data analysis:

The number of different fabrics that will make up the SAN solution

The port count and performance characteristics of each fabric

An estimate of the hardware required to meet these requirements

q       You might be able to localize traffic for better performance if you can create well-defined groups.

q       Prepare an ROI proposition to justify your SAN project.

Frequently Asked Questions

Q: Once I have designed my SAN, shouldn't it be done? I don't want to have to keep reinventing the wheel!

A: Yes and no. After a SAN enters production, it is "done" until you want to change it in a fundamental way. As long as you are happy with leaving your SAN the way it is, there is no reason why you would have to repeat the design cycle. Simply adding a new storage array does not require a repetition of the cycle. Moreover, events that do cause the cycle repeat might cause it to repeat relatively quickly. For example, if you decide to go through the design process because you are adding a new type of storage array to the SAN, and want to validate that doing so won't break anything, you will be able to take a fast track through most of the process. After all, adding this device will not by any stretch of the imagination require that you change your fabric topology, or affect much of your SAN architecture.

Q: Every end user in my company is a stakeholder in the SAN. Do I need to interview everybody?

A: It is true that everybody who uses a system is a stakeholder in that system. However, we mean something a little less broad. When we refer to a stakeholder, we mean somebody whose job revolves around taking care of one or more of the systems that will attach to the SAN. This can include systems, database, and storage administrators, as well as other technical people. It can also include people responsible for the data that resides on these systems. For example, a manager responsible for a call center at a phone-in catalog company might be a key stakeholder in the SAN, because he or she is responsible for the data entered into that company's business systemwhich is attached to the SAN. Why is this person a key stakeholder? Because he or she might have something to say about the availability and performance requirements of the system. When in doubt, try to include anybody on the team who wants to be there. It is usually better to have more data than you need, rather than less.

Q: Do I need to wait until data collection is complete before beginning data analysis?

A: Actually, the data collection and analysis phases are most effective if there is some degree of overlap. If you have analyzed data from the first interview when you go into the second, you will be able to better understand the answers, and might also be able to direct the line of questioning along more useful lines. Be careful not to develop firm convictions too early on, though. Always approach SAN design scientifically. Never start an interview with a firm preconception of the outcome! Collection and analysis are divided into two phases because some of the analysis naturally occurs after all data collection is complete. For example, you can't prepare an ROI proposition until you have a fairly complete picture of what the SAN will need to accomplish, and some idea of the technical infrastructure that will be involved.

Click here to buy book

Authors
Josh Judd is a Senior SAN Architect with Brocade Communications Systems, Inc. In addition to writing technical literature, he provides senior-level strategic support for major OEMs and end-users of Brocade storage network products worldwide. Chris Beauchamp (Brocade CFP, CSD) is a Senior SAN Architect for Brocade Communication Systems, Inc. Chris focuses on SAN design and architecture, with an emphasis on scalability and troubleshooting. Alex Neefus is the Lead Interoperability Test Engineer at Lamprey Networks, Inc. Alex has worked on developing testing tools for the SANmark program hosted by the FCIA. Benjamin F. Kuo is a Software Development Manager at TROIKA Networks. Headquartered in Westlake Village, CA, TROIKA Networks is a developer of Fibre Channel Host Bus Adapters, dynamic multipathing, and management software for Storage Area Networks.