Hey I've got some openser servers running in db-only mode on the same database. Load for them is balanced using srv records, and they can handle exactly the same traffic -> standard clustering. I wonder about procedure of shutting them down if something fails. Assuming that a new openser will be started with the same ip on another host if old one fails, should I allow old openser to shutdown as cleanly as it can, or should I cut the communication as soon as possible? What I worry about most, is -> does shutting down openser which handles a dialog at the moment cause it to send any packets that I wouldn't like to be sent in this scenario?
I think it works this way: - If I cut the communication and kill all openser processes (kill, not term), I can assign the new ip faster because old host is in unknown/failed state anyways. But it may leave some unused stuff in database. - If I allow it to close properly, it may cleanup it's state it database. But it may remove too much dialog data (which could be used by the backup host). Which one is more likely?
Thanks, Stan
Hello,
openser does not keep dialog state unless you loaded and configured the dialog module. Otherwise, openser is just transactional stateful proxy by loading and using tm module. Basically, in this configuration, it is safe to shut down openser, as there is no information stored about active calls.
Cheers, Daniel
On 06/05/08 13:54, Stanis?aw Pitucha wrote:
Hey I've got some openser servers running in db-only mode on the same database. Load for them is balanced using srv records, and they can handle exactly the same traffic -> standard clustering. I wonder about procedure of shutting them down if something fails. Assuming that a new openser will be started with the same ip on another host if old one fails, should I allow old openser to shutdown as cleanly as it can, or should I cut the communication as soon as possible? What I worry about most, is -> does shutting down openser which handles a dialog at the moment cause it to send any packets that I wouldn't like to be sent in this scenario?
I think it works this way:
- If I cut the communication and kill all openser processes (kill, not term), I can assign the new ip faster because old host is in unknown/failed state anyways. But it may leave some unused stuff in database.
- If I allow it to close properly, it may cleanup it's state it database. But it may remove too much dialog data (which could be used by the backup host).
Which one is more likely?
Thanks, Stan
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
----- "Daniel-Constantin Mierla" miconda@gmail.com wrote:
openser does not keep dialog state unless you loaded and configured the dialog module. Otherwise, openser is just transactional stateful proxy
by loading and using tm module. Basically, in this configuration, it is safe to shut down openser, as there is no information stored about active calls.
Well - those machines handle registrations and stateful calls, so I have both dialog and userloc tables shared on the cluster's database. That's why I'm concerned...
Hi Stanisław,
Dialog module is able to store the on-going dialogs and recover after a restart. The same for the usrloc module.... ...of course, as time as you use DB support for these modules.
Regards, Bogdan
Stanisław Pitucha wrote:
----- "Daniel-Constantin Mierla" miconda@gmail.com wrote:
openser does not keep dialog state unless you loaded and configured the dialog module. Otherwise, openser is just transactional stateful proxy
by loading and using tm module. Basically, in this configuration, it is safe to shut down openser, as there is no information stored about active calls.
Well - those machines handle registrations and stateful calls, so I have both dialog and userloc tables shared on the cluster's database. That's why I'm concerned...
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users