Book Excerpt: Building SANs with Brocade Fabric Switches Page 3
By Josh Judd, Chris Beauchamp, Alex Neefus and Benjamin F. Kuo
Moving from Business Requirements to Technical Requirements
You should not deploy a SAN simply for the sake of adopting the "hot new technology." SANs are hot because they solve important business problems and allow companies to make more money. This could be fairly directfor example, a matter of saving more money on IT than the project cost, since SANs are very efficient at providing a clear ROI. ROI is often achieved by management efficiencies, resource efficiencies, or better utilization of resources. On the other hand, it could be indirectby making IT systems more efficient, thus increasing users' productivity.
The first key to a successful SAN deployment is the accurate and complete statement of what business problem(s) you intend for the SAN to solve. Unfortunately, you cannot turn a business problem into a technical solution without work. There is no silver bullet to make your backups run faster so that your users will not have to work on a slow system. However, there are tape libraries that run fast, and can be shared by many devices. This, when combined with an appropriate Fibre Channel fabric, and a SAN-enabled backup application, could amount to the same thing as the silver bullet.
In order to know which hardware and software will solve your business problem, you have to define in a technical way what you need to accomplish. This is a necessary intermediate step between the business problem and the purchase of specific technical solutions.
It is fairly straightforward to change a sentence like, "We need to keep our business running in case of a disaster like an earthquake or fire" into a sentence like, "The SAN must allow all functionality of all business-critical servers at site X to resume within Y minutes at site Z." Once you have done this, you will have the business requirements of the solution. You know that you have a business requirements statement when you could phrase it like this, and still have it make sense: "Our business will run better if we have a SAN that can allow all functionality of all business-critical servers at site X to resume within Y minutes at site Z." The components of the business requirements statement are "our business will run better" (or something to that effect) followed by a reasonably specific statement about what the SAN must do to make that happen.
However, you will still not have the technical requirements detailed. This is not something that you, the SAN designer, can simply ask in an interview. This is a large part of what you will bring to the table as the SAN designer once you have gathered the data and then analyzed it in the next phase. A technical requirements document set should list, in detail:
The technical requirement statement would be, "The
SAN needed to meet the business requirements outlined must have the following
characteristics: " This would be followed by the body of the technical
requirements document. The rest of the questions to ask in the interview
process will provide you with the body of this document.
What Is Known about the Nodes that Will Attach to the
What Is Known about the Nodes that Will Attach to the SAN?
You should try to get a list of all information possible about every node attached to the SAN. For each node, the relevant information can include questions about each host, storage device, facilities where hosts and storage will be located, and questions about the SAN itself. Questions about each host could include the following:
These questions could be used to create an interview form for each host, which might look like the following:
Questions about each storage device could include the following:
Note: Obviously, some of these questions do not relate directly to the SAN deployment. However, they are generally relevant whenever making a large architectural change in a data center. For example, it is necessary to know what temperature a server can operate at in case the server is in a location where temperature control is an issue. In this case, adding a large number of switches might increase the room temperature beyond operating levels. As always, use your judgement about which questions to include in your interview, and which to skip over.
Note: While it is possible to manage an entire fabric through a single Ethernet connection, this is not the method that Brocade currently recommends. You should plan on one Ethernet connection per Brocade switch, in addition to planning connections for hosts and other SAN devices. It is also advisable for the highest availability plan to balance switches across multiple electrical circuits, even if an Uninterruptible Power Supply (UPS) protects them.
Questions about facilities where hosts and storage will be located could include the following:
Answers to questions about the SAN itself must be considered preliminary. They will indicate preconceptions that members of the core team have, but all members should be prepared to be flexible on these preconceptions as the SAN design process progresses. Questions about the SAN itself could include the following:
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.