Specifications
DATA CENTER BEST PRACTICES
SAN Design and Best Practices 25 of 84
Solution 1: Make the B-Series act more like the M-Series by using PBR versus EBR on the B-Series so that it will
have the same single ow per ISL, just like the M-Series.
Solution 2: Migrate sooner to a B-Series core and B-Series edge from B-Series core and M-Series edge (or vice
versa). Most customers nd themselves in Interop Fabrics temporarily.
Solution 3: Move the heavy hitters (microbursts) to the core (in a core-edge topology). This will reduce the trafc
on the ISLs and reduce the chances of frame congestion.
Solution 4: Install “Open Trunking” on M-Series to assist with load balancing ISLs based on ow and increase
BBCs (Buffer to Buffer Credits) on a B-Series core switch. This will allow the M-Series to send more frames
upward on the single ISL it has chosen, versus the B-Series ows downward will use ALL ISLs (EBR) and
essentially equalize the ows from a BBC standpoint.
Example: Assume that a B-Series has 3 ISLs to M-Series. In this design, each B-Series will have 8 BBCs by
default and the M-Series will have 16 by default. In this example, the B-Series will see a total of 24 BBCs
toward the McDATA, whereas the McDATA will only see 16 and upward. This may not be enough BBCs on the
single ISL to sustain the ow. The recommendation would be to assign the B-Series with 48 BBCs to equalize.
The M-Series originated ows will now be able to fully utilize the ISL with 48 BBCs from the B-Series, whereas
the M-Series will receive from the B-Series 48 total frames, as the B-Series will use all 3 ISLs to forward frames
(EBR), since each M-Series is set to 16 BBCs by default. Keep in mind, the BBC value is really a receiver
buffer setting.
Note: Refer to the Brocade FOS Release Notes for McDATA interop support. Brocade FOS 7.0 and above do not
support interoperability with the McDATA platform.
Latencies
There are many causes of latencies:
•Slow devices such as storage arrays
•Oversubscribed devices
•Long-distance links
•Servers that are not responding rapidly enough to I/O requests they have previously made
•Degraded cables and SFPs causing many retried I/Os
There is very little that can be done in the fabric to accommodate end-device latencies: they typically must
be addressed through other means. Array latencies can be dealt with by array or LUN reconguration or data
migration. Long-distance problems might require more long-distance bandwidth or reconguration of the distance
setting on the switch. Applications might require tuning to improve their performance, and failing links and SFPs
must be identied and replaced. At best, the fabric can help identify the source of the problem. Brocade has
been working hard to enhance RAS features in Brocade FOS in line with changing customer requirements. Some
of these features are described briey in the sections that follow.
Misbehaving Devices
All fabrics, regardless of the equipment vendor, are vulnerable to the effects of badly behaving devices, that is, a
server or storage device that for some reason stops functioning or starts ooding the fabric with data or control
frames. The effects of such behavior can be very severe, causing other applications to failover or even stop
completely. There is nothing that the fabric can do to anticipate this behavior. Brocade has implemented several
new features that are designed to rapidly detect a misbehaving device and isolate it from the rest of the fabric.
Isolating a single server has much less impact on applications than disabling a storage array port.