Hi,
Andreas Granig wrote:
Hi Stefan,
We're using sippy b2bua in some deployments, where we currently
implement transaction and dialog persistence using redis as a backend,
since it's simple, fast, easy-to-use and offers replication. Thus, you
can replicate states to a standby server and from there continue
processing active transactions and dialogs after a fail-over. Are there
any plans for such a thing on the road-map for sems? Do you see any
show-stoppers implementing this? Either way, I'll definitely have a look
we have implemented replication to and failover from a backup server (in
a private branch). so, no, no real show-stoppers there. we are using
sems' internal in-mem db (monitoring), so only active-passive is
How do you handle restarts on the active side and down-times on the
backup-side then, if it's all in-memory? Let's say I want to restart the
sems process for some reason without tearing down active calls, will it
load the states from disk to continue? Or if the fail-over side is down
for some minutes, will it catch up with the active side to have a
consistent state?
As it is implemented at the moment, when a passive node goes online it
first clones all the call checkpoints from the active one.
This means that any time you restart the active or the passive, a full
clone of all sessions is done, so restarts are not inexpensive. Also,
you loose all calls if both (all) nodes go down.
Some simple throttling is implemented in order to not overload the
master, but even with high number of concurrent calls, the amount of
data which is replicated is actually not that big.
That were mainly the reasons for choosing redis, since it writes changes
also to disk (handy for restarts of sippy on the active side), and with
its replication, the backup side catches up with changes automatically
after down-times, so I can load the current states when sippy starts up
during fail-over.
sounds good, I'll look at redis as alternative for the checkpoint storage.
Stefan
I'm currently just assuming a signaling-only b2bua, so no RTP is
involved in the scenarios described above.
Andreas
--
Stefan Sayer
VoIP Services Consulting and Development
Warschauer Str. 24
10243 Berlin
tel:+491621366449
sip:[email protected]
email/xmpp:[email protected]
_______________________________________________
Sems mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/sems
