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

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:

  • All of the devices that are to be attached to the SAN


  • Their locations


  • The communication patterns between them (random I/O, streaming access such as video, I/O-intensive database access)


  • Their performance characteristics (reads, writes, max/min/typical throughputs)


  • What software will run on them relative to the SAN (for example, a LAN-free backup application, or anything SAN-specific)


  • How all of this is expected to change over time (storage growth, server growth)


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

  • What operating system is installed? What patch or service pack level?


  • Are fabric HBA/controller drivers available? Are they well tested?


  • What type of connection is supported (private loop, public loop, or fabric)?


  • Which applications will run on this host (databases, e-mail, data replication, file sharing)?


  • How much storage does it require?


  • How will its storage requirements change over time?


  • Physically, what are its dimensions? How heavy is it?


  • Does it rack mount? Does it have a rack kit? Will it set on a shelf?


  • If there is a management console, what type is it? (Is it a traditional keyboard/video/mouse combo [KVM], or is it a serial connection, like a TTY?) Does it need to be permanently attached? (For example, a Sun SPARC server could have a keyboard, mouse, and monitor permanently attached, or it could be managed through a serial port attached to a modem.)


  • How many HBAs will it have?


  • If it has more than one HBA, what software will be used to provide failover or performance enhancements of multiple paths?


  • Do these interfaces exist, or do they need to be purchased? (You should keep track of every piece of equipment that you need to buy for the project, for budgeting and ROI analysis.)


  • If they exist, what are the make, model, and version information?


  • If not, what kind will be purchased to meet the objective?


  • How many Ethernet interfaces will it have?


  • In what temperature range will it operate?


  • Will it need a telephone line for management?


  • Where will the node be physically located?


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

  • What are the make, model, and version information?


  • What type of connection is supported (private loop, public loop, fabric, SCSI, SSA)?


  • How many hosts can this device serve?


  • If it is a multiport device, does it have limits on how many hosts can access it through each port?


  • Physically, what are its dimensions? How heavy is it?


  • What is its capacity in gigabytes?


  • Does it rack mount? Does it have a rack kit? Will it sit on a shelf?


  • If there is a management console, what type is it? Does it need to be permanently attached?


  • How many Fibre Channel interfaces will it have?


  • Do these interfaces exist, or do they need to be purchased?


  • If they exist, what are the make and model? If not, what kind will be purchased?


  • How many Ethernet interfaces will it have?


  • In what temperature range will it operate?


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

  • Will it need a telephone line for management?


  • Where will the node be physically located?


  • What is the firmware level?


  • For tape libraries, what is the capacity of each cartridge, number of cartridges the library can hold, number and speed of drives, and number of transports?


  • SCSI or Fibre Channel interface? What type of SCSI (wide/narrow, differential/single ended)?


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

  • Who is responsible for this facility?


  • Are there any existing optical cables, and what type?


  • Is there sufficient electrical power?


  • What about cooling?


  • Is there enough rack space?


  • What is the network infrastructure?


  • Physical access? If the location is on an upper floor, is there a freight elevator?


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

  • Are there any distance considerations? (For example, long cable runs between floors of a building, campuswide networks, or MAN/WAN connections.)


  • How many hosts will attach to the SAN?


  • How many storage devices will attach to the SAN?


  • If known at this point, do they require any-to-any connectivity? Alternately, are there groups of devices that need to communicate only among themselves?


  • Click here to buy book

    Building SANs with Brocade Fabric Switches

    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 3 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