On Thu, Nov 17, 2011 at 8:03 AM, Daniel-Constantin Mierla
<miconda@gmail.com> wrote:
Hello,
On 11/16/11 12:45 PM, Javier Gallart wrote:
[...]
All the data in Redis stays in memory, you can dump periodic snapshots to disk. Some time ago they worked in a feature called disktore, with some cache mechanism between disk and memory, but as far as I know that line was abandoned.
so if the redis goes down, then the records are lost or is doing dump of memory to disk at that time? I try to figure out if redis makes more sense than using one kamailio as a load balancer in front of two kamailios having the mtree in memory. The two with mtree will be restarted one after the other every 15 min. Load balancer can be configured to use only one, with quick fallback (100ms) to the second, or via kamctl the active kamailio with mtree is set to be used first.
That's pretty much our current configuration; instead of having a kamailio as load-balancer we are using our own softswitch that sends the calls to 2 kamailio with mtree in memory. If there is a problem with one of them, the call is quickly rerouted to the backup kamailio. We're happy with that configuration; but as the tree keeps growing the time needed for populating the db + reloading the tree increases (about 4-5 minutes currently, not really under pressure yet...). That's why we were thinking about a full in-memory solution. At this point we're going to focus our tests with this setup:
-1 redis Master server for writing, with frequent snapshots
-2 redis Slave servers
-2 kamailios, each of them reading from a slave redis stored in a shared variable for quick update via rpc
-If redis_cmd returns an error, kamailio will respond with a 503 Status so that the softswitch will send the invite to the backup kamailio
Of course this will make sense only if we're able to implement a mt_match equivalent in redis that gives an acceptable performance...
Regards
Javi
kamailio with mtree will send back a 302 which is handled by load balancer
Cheers,
Daniel