| only for RuBoard - do not distribute or recompile |
FC_AL hubs connect devices to the loop. It is a simple way to connect
Passive, which only reacts to ports being inserted into or removed from a loop.
Active, which are able to do configuration changes dynamically, based on some controlling protocol.
Some hubs can sense or manage configuration changes in the loop, including:
knowing when NL_Ports are added
knowing when NL_Ports are removed
knowing when address changes occur for an entire set of NL_Ports
switching NL_Ports into or out of a loop
Hubs also provide port bypass circuits to heal a loop when a device is removed or fails. This allows for less disruption in operations. Hubs help solve the problems of cabling devices and keeping track of which loop a device is on. With central cabling by way of the FC-AL hub, it is easy to add and remove devices from arbitrated
There are some definite advantages to using Fibre Channel hub:
Extremely fast solution for connecting peripherals and
Up to 124 NL_Ports per loop
Loop topology eliminates wiring clutter
FC-AL hubs enhance subsystem availability
FC-AL hubs provide port bypass circuits to permit hot repair
| only for RuBoard - do not distribute or recompile |
| only for RuBoard - do not distribute or recompile |
There will be more information about hubs in Chapter 4. For now, to
A server with an FC-AL shortwave host bus adapter (HBA) can connect to an FC-AL hub 500 meters away. Each of the 10 ports on the hub can connect to an FC-AL device up to 500
Cascaded hubs use one port on each hub for the hub-to-hub connection and this
Cascaded FC-AL, non-OFC, longwave hubs use the
| only for RuBoard - do not distribute or recompile |
| only for RuBoard - do not distribute or recompile |
This chapter discusses:
SAN principles
SAN terms and building blocks
SAN topologies
Other SAN considerations
In this chapter we build various SANs from the SAN building blocks.
| only for RuBoard - do not distribute or recompile |
| only for RuBoard - do not distribute or recompile |
By creating a SAN from its component
The old saying is, In theory, there is no difference between theory and practice, but in practice there is. This is true of the SAN. The theoretical limits of capacity and performance have practical limitations. Some elements of connectivity do not yet work or don t work as well as they should.
Let s fabricate some SANs. We begin with principles and concepts we want to follow, and then describe some of the terms and building blocks that apply
Then we ll create some topologies, building them up step by step. There are additional considerations besides the basic connections. Fault protection, distance, and tape backup topologies are among them.
We ll also look at legacy devices, and how to integrate them into the SAN. Legacy is a polite
Once we ve created some SANs, we ll look at SAN planning, maintenance, and management considerations. Finally, we ll wrap up with some SAN cost considerations.
We said in Chapter 1 that a SAN is an
Storage behind the server
Storage devices connected to each other
Multiple servers connected to the storage pool
Heterogeneous servers may be connected to the storage pool
Fibre Channel connectivity (FC host bus adapters and fiber
Hubs and switches
Multiple paths to devices
Not all characteristics need be present. For example, some SANs don t have heterogeneous servers, as the enterprise has
FC host bus adapters and fiber optic cable connections imply a full Fibre Channel interconnection, but that s not always possible. There s a need to connect SCSI devices to SANs. At this time, the majority of SANs back up data to SCSI tape libraries.
Some SANs don t have multiple paths to devices. These SANs
SAN-building can be a gradual process. You can build the
| only for RuBoard - do not distribute or recompile |