<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/~jcolp">Joshua Colp</a>
</h4>
<br/>
<h4>Changes (1)</h4>
<div id="page-diffs">
<table class="diff" cellpadding="0" cellspacing="0">
<tr><td class="diff-snipped" >...<br></td></tr>
<tr><td class="diff-unchanged" >| {center}{*}Figure 1. Active Component Selection{*}{center} | <br> <br></td></tr>
<tr><td class="diff-changed-lines" >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 <span class="diff-deleted-words"style="color:#999;background-color:#fdd;text-decoration:line-through;">a</span> the dedicated IP address. In Figure 1, we call this the Management Adapter. <br></td></tr>
<tr><td class="diff-unchanged" > <br>h3. State Replication <br></td></tr>
<tr><td class="diff-snipped" >...<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. Dynamic state replication allows the state of the active component to be reflected in its standby components in near real-time 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>
<div class='panelMacro'><table class='infoMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/wiki/images/icons/emoticons/information.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td>Fallback is also expected to be feasible in the future. Other types of failover (ex: active-active) may also be supported in the future.</td></tr></table></div>
<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 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 documented 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>The component is configured in a deployment via an Ice configuration file which defines how to access the Service Locator, and a minimal set of other properties. The configuration details that pertain to the technical domain of the component are defined via pushed configuration data. </p>
<h5><a name="FailoverandReplication-IceProperties"></a>Ice Properties</h5>
<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 define an Ice 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>When this property is set to true, the component will automatically set itself into an active state when started. If this property is false (or does not exist), the component will assume it is part of a replica group, and will startup to a standby mode. </p>
<h5><a name="FailoverandReplication-ConfigurationData"></a>Configuration Data</h5>
<p>Configuration data is pushed to a replica group using the approach defined on the page <a href="/wiki/display/TOP/Replication+of+Configuration+Changes" title="Replication of Configuration Changes">Replication of Configuration Changes</a>. </p>
<h4><a name="FailoverandReplication-ComponentStartupSequence"></a>Component Startup Sequence</h4>
<p>The following sequence diagram describes the basic flow of a component's startup process. </p>
<div class='table-wrap'>
<table class='confluenceTable'><tbody>
<tr>
<td class='confluenceTd'> <span class="image-wrap" style=""><img src="/wiki/download/attachments/13076639/Component+Startup+for+Replica+Groups.png?version=3&modificationDate=1305592173607" style="border: 1px solid black" /></span> </td>
</tr>
<tr>
<td class='confluenceTd'> <div class="" align="center"><b>Figure 2. Component Startup for Replica Group components.</b></div>
</td>
</tr>
</tbody></table>
</div>
</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=5&originalVersion=4">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>