26.12.2014 Views

Fabric Manager Users Guide, Version 6.1, Revision A - QLogic

Fabric Manager Users Guide, Version 6.1, Revision A - QLogic

Fabric Manager Users Guide, Version 6.1, Revision A - QLogic

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

1–Overview of the <strong>QLogic</strong> <strong>Fabric</strong> <strong>Manager</strong> Suite<br />

Multiple <strong>Fabric</strong> <strong>Manager</strong>s in a <strong>Fabric</strong><br />

NOTE:<br />

It is important that the configuration of all SMs managing a fabric have the<br />

same configuration. It is especially important that fundamental parameters<br />

such as SubnetPrefix match. It is also recommended that all redundant SMs<br />

are at the same revision level. Failure to follow these recommendations can<br />

result in fabric disruptions when SM failover occurs. Using the Configuration<br />

Consistency Checking feature, the FM can ensure that all redundant FMs<br />

have a comparable configuration. See “FM Configuration Consistency” on<br />

page 1-8 for more information.<br />

<strong>Fabric</strong> <strong>Manager</strong> Role Arbitration<br />

<strong>Fabric</strong> <strong>Manager</strong>s arbitrate for the master role using inband InfiniBand messages<br />

(For example, the SMInfo packet). The <strong>Fabric</strong> <strong>Manager</strong>s use the value of the SM<br />

Priority parameter (a configurable value in the range 0-15) and then the GUID of<br />

the port on which the <strong>Fabric</strong> <strong>Manager</strong> is running (for example, the switch or the<br />

Host Channel Adapter).<br />

The arbitration rules are:<br />

• The <strong>Fabric</strong> <strong>Manager</strong> with the highest priority value is master <strong>Fabric</strong> <strong>Manager</strong><br />

• In the case of <strong>Fabric</strong> <strong>Manager</strong>s with equally high priority value, the lowest<br />

value GUID is the master <strong>Fabric</strong> <strong>Manager</strong><br />

Master <strong>Fabric</strong> <strong>Manager</strong> Failover<br />

Failover from master to standby <strong>Fabric</strong> <strong>Manager</strong> is essentially seamless. Since<br />

the master and standby <strong>Fabric</strong> <strong>Manager</strong>s participate in a database<br />

synchronization mechanism, the new master <strong>Fabric</strong> <strong>Manager</strong> is equipped with<br />

enough data to continue managing the fabric upon takeover.<br />

The change of master <strong>Fabric</strong> <strong>Manager</strong>s does not affect data traffic, nor does it<br />

affect communication between fabric nodes and the SM/SA.<br />

Master Preservation – “Sticky” Failover<br />

Multiple <strong>Fabric</strong> <strong>Manager</strong>s in a fabric can be configured to support “sticky” failover.<br />

Normally when the user configures the <strong>Fabric</strong> <strong>Manager</strong>s, using the SM Priority<br />

value, to designate the pecking order of master and standby <strong>Fabric</strong> <strong>Manager</strong>s,<br />

that order always holds true during arbitration. Thus, upon failover of the master, a<br />

standby becomes the new master until the original master is restarted, whereby<br />

the original master reclaims the master role.<br />

1-6 IB0054608-01 B

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!