Book Excerpt: Building SANs with Brocade Fabric Switches Page 2
By Josh Judd, Chris Beauchamp, Alex Neefus and Benjamin F. Kuo
Now that you have a working prototype, and all
interested parties have signed off on it, you will begin to transition your
existing hardware onto the new SAN. If a SAN is already in place, this phase
might be as simple as adding a new node to the SAN, or changing the
Inter-Switch Link (ISL) architecture. If the SAN is completely new, it might
involve a long migration process consisting of moving one production system at
a time. In any case, there might be a need to cycle between this phase and the
release-to-production phase repeatedly. Once a component has completed the
transition onto the SAN, release to production can occur for that component.
Release to Production
Release to Production
Once a component has been transitioned onto the new
SAN, it must be tested again and then approved before becoming a part of the
enterprise's production environment. Since there might be many components that
must be transitioned and released, it might be necessary to cycle between the
transition and release-to-production phases repeatedly until all components
have entered production. After this phase is complete, the SAN will enter the
This is the useful life of the SAN. All of the benefits that prompted the SAN designer to implement the SAN in the first place are found in this phase. It is therefore desirable to have a SAN spend as much time as possible in this phase, and as little as possible in the other phases. The goal of this phase is to keep the SAN running as well as possible for as much of the time as possible, and to expand its capabilities only according to the original, tested, and approved parameters. This phase includes adding, changing, or removing components, as well as managing, monitoring, and troubleshooting existing components.
During the maintenance phase, no changes should be
made to the SAN that fall outside of the original blueprint that was
established in the previous phases. Any such change necessitates a repetition
of the entire lifecycle. For example, if the SAN were originally built using
vendor X storage arrays, an additional vendor X array could be added as part of
maintenance, but an array from vendor Y would require thought and testing
before its introduction. It might not require much thought and testing, but it
must, in any case, be looked into.
Note: Any fundamental change to the SAN requires a
repetition of the entire lifecycle.
Note: Any fundamental change to the SAN requires a repetition of the entire lifecycle.
In summary, the seven phases of the SAN design lifecycle are:
1. Data Collection Conducting Data Collection
2. Data Analysis
3. Architecture Development
4. Prototype and Test
6. Release to Production
Conducting Data Collection
The data collection phase of SAN design is the foundation upon which the SAN will be built. It is vital that the information collected in this phase be both complete and accurate. If the SAN requirements are poorly defined, it is guaranteed that the resulting SAN will meet business objectives poorly. You should therefore take your time with this phase.
Some of the information you will collect is generic to any major IT project. If you already have an established data collection process in your company, integrate the SAN-specific material from this section into that process.
Data collection consists of determining which people
you will need to interview, interviewing them, and conducting a physical
assessment of existing equipment and facilities. When this process is complete,
you will have a technical requirements document consisting of a list of the
business problems that the SAN will solve, the business requirements for the
SAN, characteristics of all devices that will be attached to it, and detailed
information about all relevant facilities. You will also have a timeline for
Creating an Interview Plan
Creating an Interview Plan
Who has a stake in the SAN solution? Well, you could argue that every person who uses a system attached to the SAN has a stake in it. While true, this is not useful for creating an interview list, because there would be too many people involved. Similarly, you could argue that only the person who initiated and "owns" the project should be consulted. Again, this is not useful, because it leaves out people who have a strong interest in the project, and might have knowledge that is critical to its success.
A balanced approach to creating an interview list is critical. You can view the people on this list as a SAN solution "core team." Think about having all of these people together in a room, and trying to solve the SAN solution problem together. Try to include everyone needed to solve the problem, but nobody else. Typically, a core team might include:
It is probable that you will be one of these people,
in addition to being the SAN designer. Unless you are an external consultant,
this is typically the case.
Once you have a list of the desired members of the core team, you must contact them and ask them to take time to help with the project. Ensure that each team member has allocated the necessary time and that their management appreciates the demands of participating in this team. As the SAN design goal of the team might require a long-term process, getting this buy-in initially will minimize disruption to the team later. Often in the past, SAN design teams did not include network administrators, as the focus was on the storage side. Experience has shown that SANs are networks, and should be coordinated with the traditional IP network groups to ensure that proper networking experience is at hand.
Whenever possible, schedule an interview as a
face-to-face, one-on-one meeting. This format will allow you to communicate the
questions and understand the answers most effectively. You should also have a
group meeting with the entire core team after conducting individual interviews.
This will allow you to resolve any differences before analyzing the data, and
review the analysis as a team.
Conducting the Interviews
Conducting the Interviews
Now that you know who to interview and have a
schedule of when you will interview them, you need to know what questions to
ask, and what format to put the collected data into. This section contains a
suggested set of questions that you should ask, and some detail on what each
question is about. It is followed with a summary that could be used to create
an interview form.
Note: Not every person you interview will be able to answer
every question. Between the members of the core team, the expertise necessary
to answer all of these questions should be completely represented. Some members
might provide conflicting answers. You will be in a key position to resolve
these differences, and achieve a compromise. It is vital that all affected
parties agree with the deployment strategy before implementation begins. What Overall Business Problem Are You Trying to
Note: Not every person you interview will be able to answer every question. Between the members of the core team, the expertise necessary to answer all of these questions should be completely represented. Some members might provide conflicting answers. You will be in a key position to resolve these differences, and achieve a compromise. It is vital that all affected parties agree with the deployment strategy before implementation begins.
What Overall Business Problem Are You Trying to Solve?
A business problem that would initiate a SAN design might be something like:
Chapter 6 discusses some of the more common business
problems that SANs can solve. Brocade maintains a series of documents that
detail specific SAN solutions. These documents are known as Brocade
SOLUTIONware configuration guidelines and are available on the Brocade Web site
Note: A SAN might be intended to solve multiple business
problems. In this case, you should separate each business problem into a
different set of questions and answers. You will correlate these during the
analysis phase. What Are the Business Requirements of the Solution?
Note: A SAN might be intended to solve multiple business problems. In this case, you should separate each business problem into a different set of questions and answers. You will correlate these during the analysis phase.
What Are the Business Requirements of the Solution?
Once you know the business problem that you need to solve, it should be easy to figure out what the business requirements of the solution must be. This is simply a matter of rephrasing the previous answers, with more specific criteria:
This is useful because it acts as a migratory step toward turning the business problem into a matching technical solution.
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.