[Spce-user] replicate spce servers

Wed Jul 19 00:16:06 EDT 2017

Hi Bill,

I can throw in a bit of experiences here as well…

I was running our platform on VMWare Vsphere 5.5 with about 20k+ subscribers, with no issues whatsoever (on a 4 core Xeon CPU)... Once the storage started to get overloaded (MySQL is pretty storage intensive) packets were getting dropped. The pain point of this platform is actually the storage.   Switched to SSD for MySQL and all works fine with now more than double the load.

Incidentally on another instance installed it on Openstack, but that has a slow storage system. We ran into trouble when we hit ~10k subscribers… Had to do some tweaking on mysql template to make it work again.  Upgrading the storage systems to SSD now…

I am very curious on the keepalived solution as I’d like to build a bit more resiliency on top of depending on VCenter/Openstack to do the failover.

Regards,
Walter.

> On 19 Jul 2017, at 1:56 AM, William Fulton <wfulton at thirdhatch.com> wrote:
> 
> Alex,
>  
> I am curious about your performance in virtualization. We have tested it on an Amazon image and had mixed result in regards to performance. So have only used bare metal in production. What kind of virtualization are you using and how is your performance?
>  
> Thanks,
> Bill
>  
>  
> From: Spce-user [mailto:spce-user-bounces at lists.sipwise.com <mailto:spce-user-bounces at lists.sipwise.com>] On Behalf Of Alex Pearson
> Sent: Tuesday, July 18, 2017 10:47 AM
> To: Dan Boghici <dboghici at sipwise.com <mailto:dboghici at sipwise.com>>; spce-user at lists.sipwise.com <mailto:spce-user at lists.sipwise.com>
> Subject: Re: [Spce-user] replicate spce servers
>  
> Good Morning,
>  
> Regarding the RTO, Great Question!  The majority the discussions with our team on this project have been focused on recovery. 
> The RTO for the proposed solution is essentially 0 as there is no disruption of operation. 
>  
> I’ll build upon my previous response by adding some of the key items we discussed that led to the current configuration. 
> After reviewing our current infrastructure we determined that we could run more efficiently by migrating to a virtual environment.
>  
>  
> We used two host machines to split the infrastructure into two separate points of failure.  Sipwise A and MYSQL A on Host A.  Sipwise B and MYSQL B on Host B.
> We keep them highly available using keepalived.  The Sipwise servers share a floating IP and the MYSQL servers share a floating IP.
> If a host goes down, the images will automatically failover to the images on the other Host.
>  
> Once that was completed all images were shut down, copied, and stored both on the local machine and a remote machine. 
> We now have a clone of our entire Sipwise environment that can be moved and powered on whenever or wherever we see fit. 
>  
> If a Sipwise or MYSQL image goes down you can replace it with a back up image with identical configuration. Which is why we wanted our data on a separate image.
>  
> In the event of a complete disaster, you maintain control of the images.  If you properly backup your data, you could dump a data backup onto the cloned system and be up and running.
>  
> I hope this helps answer the question.  Also, I am open to suggestions/ideas on ways to improve.
>  
> Regards,
>  
> Alex Pearson
>  
> From: Spce-user [mailto:spce-user-bounces at lists.sipwise.com <mailto:spce-user-bounces at lists.sipwise.com>] On Behalf Of Dan Boghici
> Sent: Tuesday, July 18, 2017 03:10
> To: spce-user at lists.sipwise.com <mailto:spce-user at lists.sipwise.com>
> Subject: Re: [Spce-user] replicate spce servers
>  
> why not buy the PRO version and save yourself unnecessary headache?
> 
> Dan
> 
>  
> On 07/18/2017 12:07 AM, Alex Pearson wrote:
> Good Afternoon,
>  
> Yes you can.  For example, we have a Sipwise A and a Sipwise B configured with a floating IP.  Then we have a MYSQL A server and MYSQL B server configured with Master-Master  replication and a floating IP.    The Sipwise A and Sipwise B servers are configured to use the floating IP of the database servers.
>  
> If Sipwise A dies, Sipwise B automatically takes over.  If MYSQL A goes down, MYSQL B takes over.  Effectively, ensuring that you are able to route calls AND secure your data in the event of a failover situation.  I hope this helps!
>  
> Alex
>  
> From: Spce-user [mailto:spce-user-bounces at lists.sipwise.com <mailto:spce-user-bounces at lists.sipwise.com>] On Behalf Of Stephen Donovan
> Sent: Monday, July 10, 2017 19:26
> To: Spce-user
> Subject: [Spce-user] replicate spce servers
>  
> Hello,
>  
> Say I wanted to replicate the databases of two spce instances where they have different ip addresses but all else is the same, same domain, etc.  the idea is to allow customers to connect to either server and process calls.  Inbound calling, I can handle the failover externally.  2nd instance would be for backup only in a remote datacenter.  I would use DNS SRV records and compatible endpoints to manage the failover for the same hostname.  I'm basically asking can I replicate the databases and expect this to work if needed in a failure scenario?
>  
> 
> Stephen
>  
> 
> 
> 
> _______________________________________________
> Spce-user mailing list
> Spce-user at lists.sipwise.com <mailto:Spce-user at lists.sipwise.com>
> https://lists.sipwise.com/listinfo/spce-user <https://lists.sipwise.com/listinfo/spce-user>
>  
> _______________________________________________
> Spce-user mailing list
> Spce-user at lists.sipwise.com <mailto:Spce-user at lists.sipwise.com>
> https://lists.sipwise.com/listinfo/spce-user <https://lists.sipwise.com/listinfo/spce-user>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20170719/01c85102/attachment-0001.html>