Book Excerpt: Building SANs with Brocade Fabric Switches Page 10
Download the authoritative guide: Enterprise Data Storage 2018: Optimizing Your Storage Infrastructure
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.
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.
Comment and Contribute
