18.07.2013 Views

Sidewinder G2 6.1.1 Administration Guide - Glossary of Technical ...

Sidewinder G2 6.1.1 Administration Guide - Glossary of Technical ...

Sidewinder G2 6.1.1 Administration Guide - Glossary of Technical ...

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

You can configure failover HA in one <strong>of</strong> two ways:<br />

HA configuration options<br />

primary-standby—In a primary-standby configuration, if the primary<br />

becomes unavailable, the standby takes over as the acting primary<br />

only until the primary becomes available again. (This option is<br />

generally used if you have <strong>Sidewinder</strong> <strong>G2</strong>s that do not share the<br />

same hardware configuration.)<br />

peer-to-peer— In a peer-to-peer configuration, both <strong>Sidewinder</strong><br />

<strong>G2</strong>s are configured as standbys with the same takeover time<br />

setting. This allows whichever <strong>Sidewinder</strong> <strong>G2</strong> boots up first to act<br />

as the primary. If the primary becomes unavailable, the peer<br />

<strong>Sidewinder</strong> <strong>G2</strong> (acting as the standby) will take over as the<br />

primary and will remain as the acting primary until it becomes<br />

unavailable, at which time the peer will again take over as the<br />

acting primary. This is the recommended failover HA<br />

configuration. However, to configure peer-to-peer HA, both<br />

<strong>Sidewinder</strong> <strong>G2</strong>s must have similar hardware configurations.<br />

When the primary is brought online, it activates both the cluster and<br />

interface IP addresses. (Remember, you must inform all users that the<br />

cluster address is the <strong>Sidewinder</strong> <strong>G2</strong> address, so all traffic still passes<br />

through the primary.) When the secondary or standby is brought<br />

online, it activates its interface IP addresses. The primary will then<br />

begin to "multicast" a heartbeat message. The heartbeat uses IPSec<br />

authentication (AH) to ensure that the messages are correct. The<br />

secondary or standby "listens" for this heartbeat.<br />

Suppose the primary is accidentally powered <strong>of</strong>f for a period <strong>of</strong> time.<br />

When the standby does not receive a heartbeat signal for a number <strong>of</strong><br />

seconds (based on the takeover setting <strong>of</strong> the standby), it sets the<br />

cluster common IP addresses on its interfaces. In the process, the<br />

standby clears its address resolution protocol (ARP) cache and<br />

attempts to generate a "gratuitous ARP." Most systems will immediately<br />

determine that the standby is now responsible for the addresses by<br />

which the primary is known, and new connections will be established<br />

through the new acting primary.<br />

Note: Unfortunately, there may be a number <strong>of</strong> reasons why the gratuitous ARP is not<br />

received: a remote system may not recognize the message, the message may be blocked by<br />

certain switches, it may fail due to timing issues, etc. Often this can be resolved by flushing<br />

the ARP caches in the remote system. Many <strong>of</strong> these remote systems have ways to shorten<br />

the time that entries stay in the ARP cache; these should be set to time periods in the three<br />

to five minute range.<br />

High Availability 16-5

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

Saved successfully!

Ooh no, something went wrong!