Book Excerpt: Building SANs with Brocade Fabric Switches - EnterpriseStorageForum.com

Book Excerpt: Building SANs with Brocade Fabric Switches


Building SANs with Brocade Fabric Switches


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

Solutions in this chapter:

  • Looking at the Overall Lifecycle of a SAN
  • Conducting Data Collection
  • Analyzing the Collected Data
  • Summary
  • Solutions Fast Track
  • Frequently Asked Questions

Introduction

We intend this book to allow you to effectively design, implement, and maintain storage networks. Doing so requires an understanding of the processes in each of the seven phases of a SAN's lifecycle, and their relationships with each other. Without taking a moment to review the process from the highest level, it is easy to get lost in the details of SAN hardware.

In this chapter, we provide that high-level view. We show how the SAN design process is really an ongoing lifecycle. We take you through the process from the moment the decision is made to deploy a SAN, through releasing the SAN to production. Then we explain the extent to which the process should be repeated when upgrades and architectural changes are needed. We also provide detail on the first two parts of the lifecycle.

The processes presented here are derived from other areas of Information Technology (IT) and they are normal parts of any large-scale IT project. For example, when implementing a SAN, you should interview people who will have a key interest in the finished productthe same is true when putting in a Local Area Network (LAN) or Wide Ares Network (WAN). Much of this material should be second nature to any IT network architect, Database Administrator (DBA), or senior systems administrator. For the more advanced users to whom these techniques are well understood in general, this chapter will serve as reference material showing how these processes are applied to SANs in particular. We have attempted in this book to provide material that will allow both the beginner and the expert alike to successfully design a SAN.

It is true that more attention must be paid to SAN design than to most other networking technologies. This is because SANs typically have more stringent availability and performance requirements than other networks. A SAN is similar to a traditional network in its requirements, but is also somewhat like a channel (for example, a CPU/RAM interconnect mechanism, or a PCI bus). Channels require very high performance, and are almost assumed to be 100 percent reliable. This is in stark contrast to the traditional Ethernet LAN, where things like five-nines uptime for all node connections, in-order packet delivery, and tuned approaches to bandwidth management are rare indeed.

Fortunately, SANs provide the tools necessary to achieve these performance and availability goals. For example, it is commonplace in a Fibre Channel SAN to use a dual-fabric approach to SAN architecture. This means having two completely separate networks for data to travel over, and potentially using both networks as active paths. While it is certainly possible to do this sort of thing using IP/Ethernet networks, it is substantially more difficult, since Fibre Channel was designed with this in mind, and Ethernet was not. The SAN designer must provide for higher availability and spend some time thinking about performance, but will know going into the process that these goals are entirely achievable.

We should also note here that the process outlined in this chapter is designed to make a complex SAN design successful. With less complex designs (that is, the majority of SAN deployments to date), it is perfectly acceptable to skip over much of the process. For example, if you are deploying a SAN with only three servers and two storage arrays, spending much time on architectural analysis is unnecessary. The complexity is presented here so that users with complex requirements will have it available to them; users with simpler scenarios can use their judgment about which bits to incorporate into their design process.

The seven phases of the lifecycle of a SAN at the very highest level can be broken down into three broad categories: design, implementation, and maintenance. The first of these, designing the SAN, includes the collection and the analysis of data, which defines the requirements of the network. We will go into detail on these first two phases of the design process in this chapter. These phases provide a solid launch pad for your journey through the remainder of the SAN's lifecycle.

The third and fourth phases of the SAN lifecyclearchitecture development and prototype testingcomplete the design process. Implementing the SAN encompasses the transition phase and the release to production phase, the fifth and sixth phases of the lifecycle. These phases are discussed in Chapters 6 and 7 of this book. Chapters 8 and 9 cover the troubleshooting, maintenance, and managementthe final phases of the lifecycle model.

When you are finished reading this chapter, you should have a solid understanding of the design processes, and have a valuable reference tool to enable project planning on any future SAN deployments.

Looking at the Overall Lifecycle of a SAN

Any SAN will go through certain phases over the course of its life. Depending on the size and complexity of the SAN, some phases might take months to complete, and some might be only glanced over. For example, a single-switch SAN does not require much in the way of network design. However, if the solution involves hundreds of devices, including storage components from many different vendors that were not already pretested and determined to be interoperable, it could require extensive testing or validation.

When an existing SAN must undergo a fundamental change, be it at the architectural level or simply the introduction of a new type of storage array, you should cycle back through the phases of SAN development. This will ensure that the critical applications running on the SAN are not unexpectedly disrupted by changes. However, when the change is fundamental but small (like adding a new type of storage array) it is possible to take a fast track through this process.

The SAN's lifecycle, which can be described at a high level as design, implementation, and maintenance, translates directly into action-oriented phases on the part of the SAN designer: data collection, data analysis, architecture development, prototype and testing, transition, release to production, and maintenance. See Figure 5.1 for a flowchart of these phases and their relationships to each other.

Figure 5.1 An Overview of the Lifecycle of a SAN

Data Collection

You must define the requirements of the SAN before building it. What business problem is being solved by the SAN? What are the overall goals of the project? To determine the requirements, you should interview all affected parties, to find out what they all hope to achieve (in other words, their goals and objectives), and develop both a detailed technical requirements document and a timeline for the project.

Data Analysis

Once you have gathered input from all parties, you must analyze it and put it into a meaningful format. The first two phases together will allow you to start with the business goals that are driving the project, and determine at a high level the necessary technical properties required of the SAN. Once this phase is completed, all business requirements should be translated into technical requirements. The technical requirements document will be created during the collection phase, and completed during the analysis phase. You will also have created a working document for a Return On Investment (ROI) proposition to justify the expense of the project.

Architecture Development

Now that you have a list of technical requirements, you will develop a SAN architecture that meets those requirements. This process will involve balancing many factors. For example, there might be a tradeoff between performance considerations and cost. It might be necessary for you to cycle back to the data collection and analysis phases to gather more input to make compromises with input from all affected parties. When finished, you will have a detailed architecture of the SAN that you intend to build. A SAN architecture includes the fabric topologies of all related fabrics, the storage vendors involved, the SAN-enabled applications being used, and other considerations that affect the overall SAN solution. This step is the most likely to be skipped over quickly when the SAN requirements are small.

Prototype and Testing

SANs deal directly with the mission-critical data of today's enterprises. When building any mission-critical solution, you must test it before releasing it to production. In this phase, you will build a prototype of the SAN solution and test it to ensure that it will function properly when released. This should be done using nonproduction systems. It might be necessary to cycle back to the architecture development phase if problems are found.

Wherever possible, build a test bed identical to the solution you are implementing. This will provide the greatest assurance of success in production. However, budgetary concerns, limits on time and space, and other factors will usually prevent this from being practical. Imagine a 200-port SAN. Now imagine 200 hosts and storage arrays plugged into it. Now imagine asking the CFO to buy another 200 devices to test with, and to provide administrators, space, power, and cooling for all of it.

Because of this, the test phase will be a balance of conducting your own testing, and leveraging other organizations' test results. Finding a document that says "vendor X already tested or certified this configuration" might be as good or better than testing it yourself. Even if the components of a solution have been tested by you and/or others to your satisfaction, you must test all aspects of the complete system prior to releasing it to production. This is due to the fundamental nature of a large networked system where interactions, timing, and other factors can produce different results from devices tested individually. The actual final test will occur during the release to production phase, but creation of the test plan should occur in this phase. At the end of this phase, all parties with an interest in the outcome of the project will approve it, and the transition to production will begin.

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.


Page 1 of 10

 
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