Hi all, I'm working on a Freeswitch HA solution. Now I'm deciding what method and DB I'll use to track calls. I have installed PostgreSQL on both servers and I configured them to replicate DB asynchronously. I would like to know if someone has experience with this kind of solution and what things do I have to contemplate to deploy a solid solution. Thanks in advanced. Federico.
On Tue, Jun 10, 2014 at 10:56 AM, Federico Castro <fcastelco@gmail.com> wrote:
Hi all, I'm working on a Freeswitch HA solution. Now I'm deciding what method and DB I'll use to track calls.
I have installed PostgreSQL on both servers and I configured them to replicate DB asynchronously.
I would like to know if someone has experience with this kind of solution and what things do I have to contemplate to deploy a solid solution.
Lots of people have experience with such a solution; it all depends on what you are trying to achieve. Personally, I recommend you setup Corosync and Pacemaker both on your PostgreSQL boxes and on your FreeSWITCH systems. I also recommend you run PostgreSQL on a separate set of boxes from FS. Both can use a lot of memory if you are running a lot of calls and/or have a lot of clients. If you need performance, I recommend using the fastest disks you can get in the PostgreSQL systems. Also install as much RAM as you can afford for the project in the PGSQL boxes. You will want redundant power supplies in each system with each supply plugged into a different circuit. You will also want redundant Ethernet connectivity to redundant switches which also have redundant power supplies. You will also want redundant cross-over connections between the pairs of boxes. Once you have Corosync and Pacemaker configured to start PGSQL and FS on their own boxes and you have tested manual fail-over, then you need to start thinking about every possible way you can make either of those two systems stop working. Think about hard drives failing, power loss, kernel panics, firewall rules blocking communication, someone accidentally removing the IP address from one of the systems (it happens), killing processes, Sofia profiles failing to load because something else is using the port, etc. Make sure you have things set up to detect and recover from any such failure. One of the best ways to do this is to actually build an external testing system which places real calls through the system and has them route back to itself to verify they made it. If it places a call and the call does not make it back to itself, then you know something failed and you can run more tests to determine what failed and reset it. Like I said, it all depends on what you are trying to accomplish. If you want really good automatic HA, you have to go to some pretty great lengths to get it. If you are OK with occasional manual intervention, then you can make some assumptions (like nobody accidentally removing your IP from the interface or telling it to stop responding to ARP or throwing up a firewall rule which blocks something). That makes the setup considerably easier, but it also means manual intervention when something like that happens. In other words, if something like that happens, you experience an outage which the HA system doesn't detect and recover from. When you get calls that service stopped working, you then have someone log in and take a look and manually fix the issue. This could take anywhere from 5 minutes to an hour or more to do, depending on how good your support is and how good your team is. So, probably the first task you should do is list all the things you want it to automatically recover from and all the things you are willing to accept causing an outage and then work on your implementation based on that plan.
Hi Eliot, thanks for your verbose response, it is really useful for me. I'm working on a duplicated FS + postgreSQL schema. The two boxes will have same HW. Both of them will run FS and postgreSQL. One will act as master and the other one as stand-by waiting for the first to fail. FS will not have more than a hundred simultaneous calls. I will read about Pacemaker and Corosync and I will update to the list about the implementation. Thanks again. 2014-06-13 10:45 GMT-03:00 Eliot Gable <egable+freeswitch@gmail.com>:
On Tue, Jun 10, 2014 at 10:56 AM, Federico Castro <fcastelco@gmail.com> wrote:
Hi all, I'm working on a Freeswitch HA solution. Now I'm deciding what method and DB I'll use to track calls.
I have installed PostgreSQL on both servers and I configured them to replicate DB asynchronously.
I would like to know if someone has experience with this kind of solution and what things do I have to contemplate to deploy a solid solution.
Lots of people have experience with such a solution; it all depends on what you are trying to achieve.
Personally, I recommend you setup Corosync and Pacemaker both on your PostgreSQL boxes and on your FreeSWITCH systems. I also recommend you run PostgreSQL on a separate set of boxes from FS. Both can use a lot of memory if you are running a lot of calls and/or have a lot of clients. If you need performance, I recommend using the fastest disks you can get in the PostgreSQL systems. Also install as much RAM as you can afford for the project in the PGSQL boxes. You will want redundant power supplies in each system with each supply plugged into a different circuit. You will also want redundant Ethernet connectivity to redundant switches which also have redundant power supplies. You will also want redundant cross-over connections between the pairs of boxes.
Once you have Corosync and Pacemaker configured to start PGSQL and FS on their own boxes and you have tested manual fail-over, then you need to start thinking about every possible way you can make either of those two systems stop working. Think about hard drives failing, power loss, kernel panics, firewall rules blocking communication, someone accidentally removing the IP address from one of the systems (it happens), killing processes, Sofia profiles failing to load because something else is using the port, etc. Make sure you have things set up to detect and recover from any such failure. One of the best ways to do this is to actually build an external testing system which places real calls through the system and has them route back to itself to verify they made it. If it places a call and the call does not make it back to itself, then you know something failed and you can run more tests to determine what failed and reset it.
Like I said, it all depends on what you are trying to accomplish. If you want really good automatic HA, you have to go to some pretty great lengths to get it. If you are OK with occasional manual intervention, then you can make some assumptions (like nobody accidentally removing your IP from the interface or telling it to stop responding to ARP or throwing up a firewall rule which blocks something). That makes the setup considerably easier, but it also means manual intervention when something like that happens. In other words, if something like that happens, you experience an outage which the HA system doesn't detect and recover from. When you get calls that service stopped working, you then have someone log in and take a look and manually fix the issue. This could take anywhere from 5 minutes to an hour or more to do, depending on how good your support is and how good your team is.
So, probably the first task you should do is list all the things you want it to automatically recover from and all the things you are willing to accept causing an outage and then work on your implementation based on that plan.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Hi Eliot and all, I keep on working in my HA solution. I’m almost done but there are some things I would like to improve. When I finish it I will share my solution with the community. I have two FS Boxes with Postgres running locally. Psql is running in read-write mode in Master node and in read-only mode in Slave. Psql is streaming data asynchronously through nodes. First thing I would like to improve: FS try to DROP some tables and delete records from sip_registrations, channels, etc. when connecting to psql and if it fails mod_sofia stops loading. This behaviour produces (in my scenary) that FS in Slave server does not start properly If it connects to local database because it is in read-only mode. To solve this I configured FS to connect to psql through virtual IP (it is always in Master node) then mod_sofia starts properly in Slave node. The problem here is that FS in slave node delete records from table in Master node when get connected. Is there any way to start FS in a “standby mode” in slave node to avoid it trying to write database? Thanks! 2014-06-16 12:05 GMT-03:00 Federico Castro <fcastelco@gmail.com>:
Hi Eliot, thanks for your verbose response, it is really useful for me.
I'm working on a duplicated FS + postgreSQL schema. The two boxes will have same HW. Both of them will run FS and postgreSQL. One will act as master and the other one as stand-by waiting for the first to fail.
FS will not have more than a hundred simultaneous calls.
I will read about Pacemaker and Corosync and I will update to the list about the implementation.
Thanks again.
2014-06-13 10:45 GMT-03:00 Eliot Gable <egable+freeswitch@gmail.com>:
On Tue, Jun 10, 2014 at 10:56 AM, Federico Castro <fcastelco@gmail.com> wrote:
Hi all, I'm working on a Freeswitch HA solution. Now I'm deciding what method and DB I'll use to track calls.
I have installed PostgreSQL on both servers and I configured them to replicate DB asynchronously.
I would like to know if someone has experience with this kind of solution and what things do I have to contemplate to deploy a solid solution.
Lots of people have experience with such a solution; it all depends on what you are trying to achieve.
Personally, I recommend you setup Corosync and Pacemaker both on your PostgreSQL boxes and on your FreeSWITCH systems. I also recommend you run PostgreSQL on a separate set of boxes from FS. Both can use a lot of memory if you are running a lot of calls and/or have a lot of clients. If you need performance, I recommend using the fastest disks you can get in the PostgreSQL systems. Also install as much RAM as you can afford for the project in the PGSQL boxes. You will want redundant power supplies in each system with each supply plugged into a different circuit. You will also want redundant Ethernet connectivity to redundant switches which also have redundant power supplies. You will also want redundant cross-over connections between the pairs of boxes.
Once you have Corosync and Pacemaker configured to start PGSQL and FS on their own boxes and you have tested manual fail-over, then you need to start thinking about every possible way you can make either of those two systems stop working. Think about hard drives failing, power loss, kernel panics, firewall rules blocking communication, someone accidentally removing the IP address from one of the systems (it happens), killing processes, Sofia profiles failing to load because something else is using the port, etc. Make sure you have things set up to detect and recover from any such failure. One of the best ways to do this is to actually build an external testing system which places real calls through the system and has them route back to itself to verify they made it. If it places a call and the call does not make it back to itself, then you know something failed and you can run more tests to determine what failed and reset it.
Like I said, it all depends on what you are trying to accomplish. If you want really good automatic HA, you have to go to some pretty great lengths to get it. If you are OK with occasional manual intervention, then you can make some assumptions (like nobody accidentally removing your IP from the interface or telling it to stop responding to ARP or throwing up a firewall rule which blocks something). That makes the setup considerably easier, but it also means manual intervention when something like that happens. In other words, if something like that happens, you experience an outage which the HA system doesn't detect and recover from. When you get calls that service stopped working, you then have someone log in and take a look and manually fix the issue. This could take anywhere from 5 minutes to an hour or more to do, depending on how good your support is and how good your team is.
So, probably the first task you should do is list all the things you want it to automatically recover from and all the things you are willing to accept causing an outage and then work on your implementation based on that plan.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
from switch.conf.xml <!-- The system will create all the db schemas automatically, set this to false to avoid this behaviour --> <!-- <param name="auto-create-schemas" value="true"/> --> <!-- <param name="auto-clear-sql" value="true"/> -->
On Dec 16, 2014, at 3:57 PM, Federico Castro <fcastelco@gmail.com> wrote:
Hi Eliot and all, I keep on working in my HA solution. I’m almost done but there are some things I would like to improve. When I finish it I will share my solution with the community.
I have two FS Boxes with Postgres running locally. Psql is running in read-write mode in Master node and in read-only mode in Slave. Psql is streaming data asynchronously through nodes.
First thing I would like to improve:
FS try to DROP some tables and delete records from sip_registrations, channels, etc. when connecting to psql and if it fails mod_sofia stops loading. This behaviour produces (in my scenary) that FS in Slave server does not start properly If it connects to local database because it is in read-only mode. To solve this I configured FS to connect to psql through virtual IP (it is always in Master node) then mod_sofia starts properly in Slave node. The problem here is that FS in slave node delete records from table in Master node when get connected.
Is there any way to start FS in a “standby mode” in slave node to avoid it trying to write database?
Thanks!
2014-06-16 12:05 GMT-03:00 Federico Castro <fcastelco@gmail.com <mailto:fcastelco@gmail.com>>: Hi Eliot, thanks for your verbose response, it is really useful for me.
I'm working on a duplicated FS + postgreSQL schema. The two boxes will have same HW. Both of them will run FS and postgreSQL. One will act as master and the other one as stand-by waiting for the first to fail.
FS will not have more than a hundred simultaneous calls.
I will read about Pacemaker and Corosync and I will update to the list about the implementation.
Thanks again.
2014-06-13 10:45 GMT-03:00 Eliot Gable <egable+freeswitch@gmail.com <mailto:egable+freeswitch@gmail.com>>: On Tue, Jun 10, 2014 at 10:56 AM, Federico Castro <fcastelco@gmail.com <mailto:fcastelco@gmail.com>> wrote: Hi all, I'm working on a Freeswitch HA solution. Now I'm deciding what method and DB I'll use to track calls.
I have installed PostgreSQL on both servers and I configured them to replicate DB asynchronously.
I would like to know if someone has experience with this kind of solution and what things do I have to contemplate to deploy a solid solution.
Lots of people have experience with such a solution; it all depends on what you are trying to achieve.
Personally, I recommend you setup Corosync and Pacemaker both on your PostgreSQL boxes and on your FreeSWITCH systems. I also recommend you run PostgreSQL on a separate set of boxes from FS. Both can use a lot of memory if you are running a lot of calls and/or have a lot of clients. If you need performance, I recommend using the fastest disks you can get in the PostgreSQL systems. Also install as much RAM as you can afford for the project in the PGSQL boxes. You will want redundant power supplies in each system with each supply plugged into a different circuit. You will also want redundant Ethernet connectivity to redundant switches which also have redundant power supplies. You will also want redundant cross-over connections between the pairs of boxes.
Once you have Corosync and Pacemaker configured to start PGSQL and FS on their own boxes and you have tested manual fail-over, then you need to start thinking about every possible way you can make either of those two systems stop working. Think about hard drives failing, power loss, kernel panics, firewall rules blocking communication, someone accidentally removing the IP address from one of the systems (it happens), killing processes, Sofia profiles failing to load because something else is using the port, etc. Make sure you have things set up to detect and recover from any such failure. One of the best ways to do this is to actually build an external testing system which places real calls through the system and has them route back to itself to verify they made it. If it places a call and the call does not make it back to itself, then you know something failed and you can run more tests to determine what failed and reset it.
Like I said, it all depends on what you are trying to accomplish. If you want really good automatic HA, you have to go to some pretty great lengths to get it. If you are OK with occasional manual intervention, then you can make some assumptions (like nobody accidentally removing your IP from the interface or telling it to stop responding to ARP or throwing up a firewall rule which blocks something). That makes the setup considerably easier, but it also means manual intervention when something like that happens. In other words, if something like that happens, you experience an outage which the HA system doesn't detect and recover from. When you get calls that service stopped working, you then have someone log in and take a look and manually fix the issue. This could take anywhere from 5 minutes to an hour or more to do, depending on how good your support is and how good your team is.
So, probably the first task you should do is list all the things you want it to automatically recover from and all the things you are willing to accept causing an outage and then work on your implementation based on that plan.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com <http://www.cudatel.com/>
Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://wiki.freeswitch.org <http://wiki.freeswitch.org/> http://www.cluecon.com <http://www.cluecon.com/>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://confluence.freeswitch.org <http://confluence.freeswitch.org/> http://www.cluecon.com <http://www.cluecon.com/>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/>
are your servers in same LAN or they are in the " cloud " ? 2014-12-17 17:08 GMT-05:00 Michael Jerris <mike@jerris.com>:
from switch.conf.xml
<!-- The system will create all the db schemas automatically, set this to false to avoid this behaviour --> <!-- <param name="auto-create-schemas" value="true"/> --> <!-- <param name="auto-clear-sql" value="true"/> -->
On Dec 16, 2014, at 3:57 PM, Federico Castro <fcastelco@gmail.com> wrote:
Hi Eliot and all, I keep on working in my HA solution. I'm almost done but there are some things I would like to improve. When I finish it I will share my solution with the community.
I have two FS Boxes with Postgres running locally. Psql is running in read-write mode in Master node and in read-only mode in Slave. Psql is streaming data asynchronously through nodes.
First thing I would like to improve:
FS try to DROP some tables and delete records from sip_registrations, channels, etc. when connecting to psql and if it fails mod_sofia stops loading. This behaviour produces (in my scenary) that FS in Slave server does not start properly If it connects to local database because it is in read-only mode. To solve this I configured FS to connect to psql through virtual IP (it is always in Master node) then mod_sofia starts properly in Slave node. The problem here is that FS in slave node delete records from table in Master node when get connected.
Is there any way to start FS in a "standby mode" in slave node to avoid it trying to write database?
Thanks!
2014-06-16 12:05 GMT-03:00 Federico Castro <fcastelco@gmail.com>:
Hi Eliot, thanks for your verbose response, it is really useful for me.
I'm working on a duplicated FS + postgreSQL schema. The two boxes will have same HW. Both of them will run FS and postgreSQL. One will act as master and the other one as stand-by waiting for the first to fail.
FS will not have more than a hundred simultaneous calls.
I will read about Pacemaker and Corosync and I will update to the list about the implementation.
Thanks again.
2014-06-13 10:45 GMT-03:00 Eliot Gable <egable+freeswitch@gmail.com>:
On Tue, Jun 10, 2014 at 10:56 AM, Federico Castro <fcastelco@gmail.com> wrote:
Hi all, I'm working on a Freeswitch HA solution. Now I'm deciding what method and DB I'll use to track calls.
I have installed PostgreSQL on both servers and I configured them to replicate DB asynchronously.
I would like to know if someone has experience with this kind of solution and what things do I have to contemplate to deploy a solid solution.
Lots of people have experience with such a solution; it all depends on what you are trying to achieve.
Personally, I recommend you setup Corosync and Pacemaker both on your PostgreSQL boxes and on your FreeSWITCH systems. I also recommend you run PostgreSQL on a separate set of boxes from FS. Both can use a lot of memory if you are running a lot of calls and/or have a lot of clients. If you need performance, I recommend using the fastest disks you can get in the PostgreSQL systems. Also install as much RAM as you can afford for the project in the PGSQL boxes. You will want redundant power supplies in each system with each supply plugged into a different circuit. You will also want redundant Ethernet connectivity to redundant switches which also have redundant power supplies. You will also want redundant cross-over connections between the pairs of boxes.
Once you have Corosync and Pacemaker configured to start PGSQL and FS on their own boxes and you have tested manual fail-over, then you need to start thinking about every possible way you can make either of those two systems stop working. Think about hard drives failing, power loss, kernel panics, firewall rules blocking communication, someone accidentally removing the IP address from one of the systems (it happens), killing processes, Sofia profiles failing to load because something else is using the port, etc. Make sure you have things set up to detect and recover from any such failure. One of the best ways to do this is to actually build an external testing system which places real calls through the system and has them route back to itself to verify they made it. If it places a call and the call does not make it back to itself, then you know something failed and you can run more tests to determine what failed and reset it.
Like I said, it all depends on what you are trying to accomplish. If you want really good automatic HA, you have to go to some pretty great lengths to get it. If you are OK with occasional manual intervention, then you can make some assumptions (like nobody accidentally removing your IP from the interface or telling it to stop responding to ARP or throwing up a firewall rule which blocks something). That makes the setup considerably easier, but it also means manual intervention when something like that happens. In other words, if something like that happens, you experience an outage which the HA system doesn't detect and recover from. When you get calls that service stopped working, you then have someone log in and take a look and manually fix the issue. This could take anywhere from 5 minutes to an hour or more to do, depending on how good your support is and how good your team is.
So, probably the first task you should do is list all the things you want it to automatically recover from and all the things you are willing to accept causing an outage and then work on your implementation based on that plan.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Thanks Mike, I will put these parameters to false. Luis, they are in the same LAN. 2014-12-17 21:19 GMT-03:00 Luis Daniel Lucio Quiroz < luis.daniel.lucio@gmail.com>:
are your servers in same LAN or they are in the " cloud " ?
2014-12-17 17:08 GMT-05:00 Michael Jerris <mike@jerris.com>:
from switch.conf.xml
<!-- The system will create all the db schemas automatically, set this to false to avoid this behaviour --> <!-- <param name="auto-create-schemas" value="true"/> --> <!-- <param name="auto-clear-sql" value="true"/> -->
On Dec 16, 2014, at 3:57 PM, Federico Castro <fcastelco@gmail.com> wrote:
Hi Eliot and all, I keep on working in my HA solution. I'm almost done but there are some things I would like to improve. When I finish it I will share my solution with the community.
I have two FS Boxes with Postgres running locally. Psql is running in read-write mode in Master node and in read-only mode in Slave. Psql is streaming data asynchronously through nodes.
First thing I would like to improve:
FS try to DROP some tables and delete records from sip_registrations, channels, etc. when connecting to psql and if it fails mod_sofia stops loading. This behaviour produces (in my scenary) that FS in Slave server does not start properly If it connects to local database because it is in read-only mode. To solve this I configured FS to connect to psql through virtual IP (it is always in Master node) then mod_sofia starts properly in Slave node. The problem here is that FS in slave node delete records from table in Master node when get connected.
Is there any way to start FS in a "standby mode" in slave node to avoid it trying to write database?
Thanks!
2014-06-16 12:05 GMT-03:00 Federico Castro <fcastelco@gmail.com>:
Hi Eliot, thanks for your verbose response, it is really useful for me.
I'm working on a duplicated FS + postgreSQL schema. The two boxes will have same HW. Both of them will run FS and postgreSQL. One will act as master and the other one as stand-by waiting for the first to fail.
FS will not have more than a hundred simultaneous calls.
I will read about Pacemaker and Corosync and I will update to the list about the implementation.
Thanks again.
2014-06-13 10:45 GMT-03:00 Eliot Gable <egable+freeswitch@gmail.com>:
On Tue, Jun 10, 2014 at 10:56 AM, Federico Castro <fcastelco@gmail.com
wrote:
Hi all, I'm working on a Freeswitch HA solution. Now I'm deciding what method and DB I'll use to track calls.
I have installed PostgreSQL on both servers and I configured them to replicate DB asynchronously.
I would like to know if someone has experience with this kind of solution and what things do I have to contemplate to deploy a solid solution.
Lots of people have experience with such a solution; it all depends on what you are trying to achieve.
Personally, I recommend you setup Corosync and Pacemaker both on your PostgreSQL boxes and on your FreeSWITCH systems. I also recommend you run PostgreSQL on a separate set of boxes from FS. Both can use a lot of memory if you are running a lot of calls and/or have a lot of clients. If you need performance, I recommend using the fastest disks you can get in the PostgreSQL systems. Also install as much RAM as you can afford for the project in the PGSQL boxes. You will want redundant power supplies in each system with each supply plugged into a different circuit. You will also want redundant Ethernet connectivity to redundant switches which also have redundant power supplies. You will also want redundant cross-over connections between the pairs of boxes.
Once you have Corosync and Pacemaker configured to start PGSQL and FS on their own boxes and you have tested manual fail-over, then you need to start thinking about every possible way you can make either of those two systems stop working. Think about hard drives failing, power loss, kernel panics, firewall rules blocking communication, someone accidentally removing the IP address from one of the systems (it happens), killing processes, Sofia profiles failing to load because something else is using the port, etc. Make sure you have things set up to detect and recover from any such failure. One of the best ways to do this is to actually build an external testing system which places real calls through the system and has them route back to itself to verify they made it. If it places a call and the call does not make it back to itself, then you know something failed and you can run more tests to determine what failed and reset it.
Like I said, it all depends on what you are trying to accomplish. If you want really good automatic HA, you have to go to some pretty great lengths to get it. If you are OK with occasional manual intervention, then you can make some assumptions (like nobody accidentally removing your IP from the interface or telling it to stop responding to ARP or throwing up a firewall rule which blocks something). That makes the setup considerably easier, but it also means manual intervention when something like that happens. In other words, if something like that happens, you experience an outage which the HA system doesn't detect and recover from. When you get calls that service stopped working, you then have someone log in and take a look and manually fix the issue. This could take anywhere from 5 minutes to an hour or more to do, depending on how good your support is and how good your team is.
So, probably the first task you should do is list all the things you want it to automatically recover from and all the things you are willing to accept causing an outage and then work on your implementation based on that plan.
Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (4)
-
Eliot Gable
-
Federico Castro
-
Luis Daniel Lucio Quiroz
-
Michael Jerris