Changes between Version 3 and Version 4 of TBFailOver
- Timestamp:
- Mar 3, 2011, 1:43:01 PM (13 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TBFailOver
v3 v4 1 1 [[PageOutline(2-4)]] 2 = = Failover Testbed ==2 = Failover Testbed = 3 3 4 One of the great improvements of Diameter is the '''failover''' mechanism. 4 == Failover and Failback == 5 One of the great properties of Diameter is the '''failover''' mechanism, which allows more reliable delivery of messages (especially important for accounting/billing). 5 6 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.7 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, otherwise an error is returned to the client). The request will reach the final destination through a different route. 7 8 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.9 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 stack. 9 10 10 The '''failback''' term means that after a connection has been restored, new messages are again sent to this peer.11 The '''failback''' term means that after a connection has been restored, new messages are again sent over it. 11 12 12 Failover and failback are '''natively supported''' by the {{{freeDiameter}}} daemon. 13 Failover and failback are natively supported by the {{{freeDiameter}}} framework. 14 15 == Testbed Description == 13 16 14 17 This 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}}}). 15 18 16 The client and server are using the [wiki:test_app.fdx test_app] application to exchange messages. The routingconfiguration allows the messages to be conveyed through one of the relays, but not directly between the client and server.19 The 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. 17 20 18 21 In the graph bellow, the blue route is the primary route, and green is secondary in case the primary route is down. … … 45 48 }}} 46 49 47 == = Screencast ===50 == Screencast == 48 51 49 52 The demonstration is split across two videos, because of its length. 50 It is recommended to watch the video in HD and fullscreen .53 It is recommended to watch the video in HD and fullscreen, with the subtitles. 51 54 52 === = First video: preparation of the testbed. ====55 === First video: preparation of the testbed. === 53 56 [[Embed(youtube=sTlunjatL_w&hd=1,w=660,h=525)]] 54 57 … … 62 65 * (3:28 ~ 4:35) Confirm the basic behavior of Test application (see [wiki:TBSimple Simple Testbed] for detail). 63 66 64 === = Second video: Failover experiments. ====67 === Second video: Failover experiments. === 65 68 [[Embed(youtube=9YyZpB8JHyA&hd=1,w=660,h=525)]] 66 69 … … 80 83 81 84 82 == = Configuration files ===85 == Configuration files == 83 86 84 87 Please note that these files may have been updated since the time the video was created. However, the purpose of the testbed remains the same. 85 88 86 === = Scripts ====89 === Scripts === 87 90 There is no script demonstrated in this video. Anyway, you might find the scripts from the [wiki:TBSimple Simple Testbed] useful also here. 88 91 89 === = nas.a.rt.testbed.aaa ====92 === nas.a.rt.testbed.aaa === 90 93 91 94 These are the configuration files for freeDiameter on the client: … … 106 109 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. 107 110 108 === = proxy.a.rt.testbed.aaa ====111 === proxy.a.rt.testbed.aaa === 109 112 110 113 The following details of the configuration files should be highlighted: … … 112 115 [source:VirtualTestbed/conf/proxy.a.rt.testbed.aaa/freeDiameter/CMakeFlags CMakeFlags]:: 113 116 * {{{-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. 116 119 117 120 [source:VirtualTestbed/conf/proxy.a.rt.testbed.aaa/freeDiameter/freeDiameter.conf freeDiameter.conf]:: 118 121 * The {{{NoRelay}}} directive is commented out here. 119 * The only peer to which this relay actively tries to connect is the other p eer. It does not initiate connections to the client or server.120 * It loads the [wiki:acl_wl.fdx] extension, t hat 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. 121 124 122 125 [source:VirtualTestbed/conf/proxy.a.rt.testbed.aaa/freeDiameter/acl_wl.conf acl_wl.conf]:: 123 126 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. 124 127 125 === = proxy.b.rt.testbed.aaa ====128 === proxy.b.rt.testbed.aaa === 126 129 127 130 The configuration files are very similar to the other relay, the same explanation apply. … … 129 132 The 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. 130 133 131 === = serv.b.rt.testbed.aaa ====134 === serv.b.rt.testbed.aaa === 132 135 133 136 The 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.
