Navigation


Changes between Version 3 and Version 4 of TBFailOver


Ignore:
Timestamp:
Mar 3, 2011, 1:43:01 PM (13 years ago)
Author:
Administrator
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • TBFailOver

    v3 v4  
    11[[PageOutline(2-4)]]
    2 == Failover Testbed ==
     2= Failover Testbed =
    33
    4 One of the great improvements of Diameter is the '''failover''' mechanism.
     4== Failover and Failback ==
     5One of the great properties of Diameter is the '''failover''' mechanism, which allows more reliable delivery of messages (especially important for accounting/billing).
    56
    6 This mechanism works as follow: after a request has been sent or relayed by a node, if the connection it was sent over is teared down before the corresponding answer is received, the request must be sent again through another connection (when possible). The request will reach the final destination through a different route.
     7This mechanism works as follow: after a request has been sent or relayed by a node, if the connection it was sent over is teared down before the corresponding answer is received, the request must be sent again through another connection (when possible, otherwise an error is returned to the client). The request will reach the final destination through a different route.
    78
    8 Coupled with the watchdog mechanism of Diameter, this failover mechanism ensures that all requests receive an answer (which can be an error). The main drawbacks are that the same request may be received several times by the server (duplicates), and that there is no limit of time for receiving the answer to a message, which can create congestion in the Diameter network.
     9Coupled with the watchdog mechanism of Diameter, this failover mechanism ensures that all requests receive an answer (which can be an error). The main drawbacks are that the same request may be received several times by the server (duplicates), and that there is no limit of time for receiving the answer to a message, which can create congestion in the Diameter stack.
    910
    10 The '''failback''' term means that after a connection has been restored, new messages are again sent to this peer.
     11The '''failback''' term means that after a connection has been restored, new messages are again sent over it.
    1112
    12 Failover and failback are '''natively supported''' by the {{{freeDiameter}}} daemon.
     13Failover and failback are natively supported by the {{{freeDiameter}}} framework.
     14
     15== Testbed Description ==
    1316
    1417This testbed involves 4 nodes in two different realms: a client ({{{nas}}} in realm {{{a}}}), two relays ({{{proxy}}} in realm {{{a}}}, and {{{proxy}}} in realm {{{b}}}), and a server ({{{serv}}} in realm {{{b}}}).
    1518
    16 The client and server are using the [wiki:test_app.fdx test_app] application to exchange messages. The routing configuration allows the messages to be conveyed through one of the relays, but not directly between the client and server.
     19The client and server are using the [wiki:test_app.fdx] application to exchange messages. The configuration allows the messages to be conveyed through one of the relays, but not directly between the client and server.
    1720
    1821In the graph bellow, the blue route is the primary route, and green is secondary in case the primary route is down.
     
    4548}}}
    4649
    47 === Screencast ===
     50== Screencast ==
    4851
    4952The demonstration is split across two videos, because of its length.
    50 It is recommended to watch the video in HD and fullscreen.
     53It is recommended to watch the video in HD and fullscreen, with the subtitles.
    5154
    52 ==== First video: preparation of the testbed. ====
     55=== First video: preparation of the testbed. ===
    5356[[Embed(youtube=sTlunjatL_w&hd=1,w=660,h=525)]]
    5457
     
    6265 * (3:28 ~ 4:35) Confirm the basic behavior of Test application (see [wiki:TBSimple Simple Testbed] for detail).
    6366
    64 ==== Second video: Failover experiments. ====
     67=== Second video: Failover experiments. ===
    6568[[Embed(youtube=9YyZpB8JHyA&hd=1,w=660,h=525)]]
    6669
     
    8083
    8184
    82 === Configuration files ===
     85== Configuration files ==
    8386
    8487Please note that these files may have been updated since the time the video was created. However, the purpose of the testbed remains the same.
    8588
    86 ==== Scripts ====
     89=== Scripts ===
    8790There is no script demonstrated in this video. Anyway, you might find the scripts from the [wiki:TBSimple Simple Testbed] useful also here.
    8891
    89 ==== nas.a.rt.testbed.aaa ====
     92=== nas.a.rt.testbed.aaa ===
    9093
    9194These are the configuration files for freeDiameter on the client:
     
    106109   Configuration file for the [wiki:rt_default.fdx] extension. We indicate to the daemon that all messages can be sent to the local relay ({{{proxy.a.rt.testbed.aaa}}}) by default, if no better route is available.
    107110
    108 ==== proxy.a.rt.testbed.aaa ====
     111=== proxy.a.rt.testbed.aaa ===
    109112
    110113The following details of the configuration files should be highlighted:
     
    112115 [source:VirtualTestbed/conf/proxy.a.rt.testbed.aaa/freeDiameter/CMakeFlags CMakeFlags]::
    113116    * {{{-DBUILD_DBG_RT:BOOL=ON}}} : compile the [wiki:dbg_rt.fdx] extension.
    114     * Note that the [wiki:acl_wl.fdx] extension is also built (by default).
    115     * Note also that the [wiki:test_app.fdx] extension is '''not''' built on the relay: the node does not need to understand fully the message in order to relay it.
     117    * The [wiki:acl_wl.fdx] extension is also built (by default).
     118    * The [wiki:test_app.fdx] extension is '''not''' built on the relay: the node does not need to understand fully the message in order to relay it.
    116119
    117120 [source:VirtualTestbed/conf/proxy.a.rt.testbed.aaa/freeDiameter/freeDiameter.conf freeDiameter.conf]::
    118121    * The {{{NoRelay}}} directive is commented out here.
    119     * The only peer to which this relay actively tries to connect is the other peer. It does not initiate connections to the client or server.
    120     * It loads the [wiki:acl_wl.fdx] extension, that enables incoming connections from other peers.
     122    * The only peer to which this relay actively tries to connect is the other proxy. It does not initiate connections to the client or server.
     123    * It loads the [wiki:acl_wl.fdx] extension, to enable incoming connections from client and server.
    121124
    122125 [source:VirtualTestbed/conf/proxy.a.rt.testbed.aaa/freeDiameter/acl_wl.conf acl_wl.conf]::
    123126   The configuration file passed to the [wiki:acl_wl.fdx] extension. The meaning here is that any node that claims a Diameter Identity that matches the expression "*.rt.testbed.aaa" is allowed to connect to this peer.
    124127
    125 ==== proxy.b.rt.testbed.aaa ====
     128=== proxy.b.rt.testbed.aaa ===
    126129
    127130The configuration files are very similar to the other relay, the same explanation apply.
     
    129132The file [source:VirtualTestbed/conf/proxy.b.rt.testbed.aaa/freeDiameter/CMakeFlags-altlibs CMakeFlags-altlibs] is an informational example on how to link {{{freeDiameter}}} against a non-default GNUTLS library.
    130133
    131 ==== serv.b.rt.testbed.aaa ====
     134=== serv.b.rt.testbed.aaa ===
    132135
    133136The configuration files for the server can be found [source:VirtualTestbed/conf/serv.b.rt.testbed.aaa/freeDiameter/ in this folder]. There is nothing special to add here.