Book Excerpt: Building SANs with Brocade Fabric Switches Page 2 -

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

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 maintenance phase.


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.

In summary, the seven phases of the SAN design lifecycle are:

1. Data Collection
2. Data Analysis
3. Architecture Development
4. Prototype and Test
5. Transition
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 implementation.

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:

  • At least one systems administrator

  • At least one storage administrator

  • A network administrator

  • A DBA, if a database server will be involved

  • At least one application specialist associated with each application that will run on the SAN

  • At least one manager who can act as an overall "owner" of the project

  • 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

    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 Solve?

    A business problem that would initiate a SAN design might be something like:

  • "We need to keep our business running in case of a disaster like an earthquake or fire."

  • "Our backups take so long to finish that they are impacting our ability to process customer orders."

  • "We need to save money on storage by utilizing free space more efficiently."

  • 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 at

    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:

  • "The SAN must allow all functionality of all business-critical servers at site X to resume within Y minutes at site Z."

  • "The SAN must allow the following list of servers to complete backups within X minutes: "

  • "The SAN must allow the following list of servers access to the corresponding list of storage arrays: "

  • This is useful because it acts as a migratory step toward turning the business problem into a matching technical solution.

    Click here to buy book

    Building SANs with Brocade Fabric Switches

    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.

    Page 2 of 10

    Previous Page
    1 2 3 4 5 6 7 8 9 10
    Next Page

    Comment and Contribute


    (Maximum characters: 1200). You have characters left.



    Storage Daily
    Don't miss an article. Subscribe to our newsletter below.

    Thanks for your registration, follow us on our social networks to keep up-to-date