<html>
<head>
<base href="https://wiki.asterisk.org/wiki">
<link rel="stylesheet" href="/wiki/s/2042/1/7/_/styles/combined.css?spaceKey=TOP&forWysiwyg=true" type="text/css">
</head>
<body style="background: white;" bgcolor="white" class="email-body">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
<h2><a href="https://wiki.asterisk.org/wiki/display/TOP/Failover+and+Replication">Failover and Replication</a></h2>
<h4>Page <b>edited</b> by <a href="https://wiki.asterisk.org/wiki/display/~khunt">Ken Hunt</a>
</h4>
<br/>
<h4>Changes (1)</h4>
<div id="page-diffs">
<table class="diff" cellpadding="0" cellspacing="0">
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">h3. Overview <br> <br>Asterisk SCF is defined to support fault tolerance when deployed in conjunction with certain platform-specific enabling technologies. The primary mechanism for this is by supporting Active-Standby failover. In Active-Standby failover, a specific component has at least two instances running. One is in active mode and is processing requests in the Asterisk SCF system. All other instances are in standby mode in the event of failure or planned shutdown of the active component. A system of dynamic state replication allows the state of the active component to be reflected in its standby components so that a standby is ready to be activated with a minimal amount of disruption of services to the rest of the Asterisk SCF system that rely on the component. <br> <br>h3. Replication Groups and the Replica Interface <br> <br>We refer to a set of same-type components, where one is active and another one or more are in standby mode (to takeover in the event of failover), as a *replica group*. Each component that supports replication is required to implement the *Replica* interface in the AsteriskSCF.System.Component namespace, which provides *activate()* and *standby()* operations to control the component's roles in the replica group. During startup, every component that participates in a replica group will initialize itself to standby mode. <br> <br>The determination of which component is active and which is standby is expected to be made by configuring technologies external to Asterisk SCF. Examples of such technologies would be Pacemaker or Windows Cluster Server. Asterisk SCF provides a python script which has access to the Replica interfaces of the Asterisk SCF components to provide a mechanism for these external technologies to activate specific component instances. This script is used both to activate a component in a replica group during startup as well as to activate a standby component when a failure is detected, or the previously active component needs to be shut down for maintenance. <br> <br>| !ReplicaManagement.png|border=0! | <br>| {center}{*}Figure 1. Active Component Selection{*}{center} | <br> <br>As depicted by a switch in Figure 1, a key concept in the failover process is the notion of a movable IP address. The connection labled "Shared" in the diagram is actually moved from one node to another by the external failover system. To maintain communication with and control of every component in a replica group, we require another dedicated IP address for each node. The Component developer must ensure that the Replica interface is created on an [Object Adapter|http://www.zeroc.com/doc/Ice-3.4.1-IceTouch/manual/Adv_server.33.4.html] that can be configured to be on a the dedicated IP address. In Figure 1, we call this the Management Adapter. <br> <br>h3. State Replication <br> <br>To support fast activation of standby components, Asterisk SCF uses a dynamic state replication approach that keeps standby components up-to-date with the internal state changes of the active component. This is document on the page [State Replication|State Replication]. <br> <br>h3. Component Configuration <br> <br>To get a reference to the State Replicator that an active component sends updates to, and a standby component listens to, each component in a replica group should use a property named: <br>{noformat} <br> <AdapterName>.StateReplicatorName <br>{noformat} <br> <br>To run a component that is designed to support replication outside of a replica group, the component should have this property set: <br>{noformat} <br> <AdapterName>.Standalone=true <br>{noformat} <br> <br>If this property does not exist, the component will assume it is part of a replica group. <br></td></tr>
</table>
</div> <h4>Full Content</h4>
<div class="notificationGreySide">
<h3><a name="FailoverandReplication-Overview"></a>Overview </h3>
<p>Asterisk SCF is defined to support fault tolerance when deployed in conjunction with certain platform-specific enabling technologies. The primary mechanism for this is by supporting Active-Standby failover. In Active-Standby failover, a specific component has at least two instances running. One is in active mode and is processing requests in the Asterisk SCF system. All other instances are in standby mode in the event of failure or planned shutdown of the active component. A system of dynamic state replication allows the state of the active component to be reflected in its standby components so that a standby is ready to be activated with a minimal amount of disruption of services to the rest of the Asterisk SCF system that rely on the component. </p>
<h3><a name="FailoverandReplication-ReplicationGroupsandtheReplicaInterface"></a>Replication Groups and the Replica Interface</h3>
<p>We refer to a set of same-type components, where one is active and another one or more are in standby mode (to takeover in the event of failover), as a <b>replica group</b>. Each component that supports replication is required to implement the <b>Replica</b> interface in the AsteriskSCF.System.Component namespace, which provides <b>activate()</b> and <b>standby()</b> operations to control the component's roles in the replica group. During startup, every component that participates in a replica group will initialize itself to standby mode. </p>
<p>The determination of which component is active and which is standby is expected to be made by configuring technologies external to Asterisk SCF. Examples of such technologies would be Pacemaker or Windows Cluster Server. Asterisk SCF provides a python script which has access to the Replica interfaces of the Asterisk SCF components to provide a mechanism for these external technologies to activate specific component instances. This script is used both to activate a component in a replica group during startup as well as to activate a standby component when a failure is detected, or the previously active component needs to be shut down for maintenance. </p>
<div class='table-wrap'>
<table class='confluenceTable'><tbody>
<tr>
<td class='confluenceTd'> <span class="image-wrap" style=""><img src="/wiki/download/attachments/13076639/ReplicaManagement.png?version=1&modificationDate=1305570306470" style="border: 0px solid black" /></span> </td>
</tr>
<tr>
<td class='confluenceTd'> <div class="" align="center"><b>Figure 1. Active Component Selection</b></div>
</td>
</tr>
</tbody></table>
</div>
<p>As depicted by a switch in Figure 1, a key concept in the failover process is the notion of a movable IP address. The connection labled "Shared" in the diagram is actually moved from one node to another by the external failover system. To maintain communication with and control of every component in a replica group, we require another dedicated IP address for each node. The Component developer must ensure that the Replica interface is created on an <a href="http://www.zeroc.com/doc/Ice-3.4.1-IceTouch/manual/Adv_server.33.4.html" class="external-link" rel="nofollow">Object Adapter</a> that can be configured to be on a the dedicated IP address. In Figure 1, we call this the Management Adapter. </p>
<h3><a name="FailoverandReplication-StateReplication"></a>State Replication</h3>
<p>To support fast activation of standby components, Asterisk SCF uses a dynamic state replication approach that keeps standby components up-to-date with the internal state changes of the active component. This is document on the page <a href="/wiki/display/TOP/State+Replication" title="State Replication">State Replication</a>. </p>
<h3><a name="FailoverandReplication-ComponentConfiguration"></a>Component Configuration</h3>
<p>To get a reference to the State Replicator that an active component sends updates to, and a standby component listens to, each component in a replica group should use a property named:</p>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre> <AdapterName>.StateReplicatorName
</pre>
</div></div>
<p>To run a component that is designed to support replication outside of a replica group, the component should have this property set:</p>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre> <AdapterName>.Standalone=true
</pre>
</div></div>
<p>If this property does not exist, the component will assume it is part of a replica group. </p>
</div>
<div id="commentsSection" class="wiki-content pageSection">
<div style="float: right;">
<a href="https://wiki.asterisk.org/wiki/users/viewnotifications.action" class="grey">Change Notification Preferences</a>
</div>
<a href="https://wiki.asterisk.org/wiki/display/TOP/Failover+and+Replication">View Online</a>
|
<a href="https://wiki.asterisk.org/wiki/pages/diffpagesbyversion.action?pageId=13076639&revisedVersion=2&originalVersion=1">View Changes</a>
|
<a href="https://wiki.asterisk.org/wiki/display/TOP/Failover+and+Replication?showComments=true&showCommentArea=true#addcomment">Add Comment</a>
</div>
</div>
</div>
</div>
</div>
</body>
</html>