From: Michael K. <li...@mk...> - 2018-07-22 09:40:21
|
> Am 22.07.2018 um 09:35 schrieb Michael Knill <mic...@ip...>: > > Thanks Lonnie > > Yes I agree totally. But there is also another factor which is restoration time and a broken Astlinux box have a much longer restoration time than all the others. Yes, that's a valid point. It seems it is much depending where in the world you live: Lonnie's order of a Qotom box was delivered after a few days, mine took 11 days. The Jetway boxes are also often not in stock. So it might be good to good to have some spare hardware. > I have actually had a couple of storage issues and a lightning strike so it certainly happens and I don't know the longevity of the new Qotom boxes so I need insurance! > > Regards > Michael Knill > > On 22/7/18, 3:06 am, "Lonnie Abelbeck" <li...@lo...> wrote: > > Hi Michael, > > I don't have any experience to comment on your hot standby solution, but just some birds-eye-view thoughts ... > > 1) Make sure your High Availability solution doesn't create more problems than it solves. > > 2) Solve possible availability issues in order of likelihood. > > For example, consider the following table of "Availability Normalized Probability" (of my own creation) ... > > Availability Normalized Probability > =================================== > 99) Power outage > > 95) Upstream network issue > > 80) Upstream SIP provider issue > > 10) Software misconfiguration (human) error > > 04) Local network issue (switch, cable, etc.) > > 03) AstLinux hardware issue (failed storage, power supply, etc.) > > <1) Astroid strike > == > > Note: The above table is a work in progress. > > For example, it makes little sense to provide redundant network switches if there is no Uninterruptible Power Supply or WAN failover. > > My 2 cents. > > Lonnie > > >> On Jul 20, 2018, at 8:11 PM, Michael Knill <mic...@ip...> wrote: >> >> Hi Group >> >> I have won a reasonable size customer (90 extensions) and Im currently testing Astlinux hot standby. >> This is what I am planning to do: >> • The Astlinux HS is in parallel to the primary Astlinux server with different IP Addresses on the internal and external interface but same subnet. Its likely that these systems will be behind a firewall using NAT. The SIP Trunk will be registered and not IP Address based. >> • The primary server periodically synchronises its config and database to the HS server. I can basically use my standard backup and restore script to do this >> • Both servers are remotely accessible >> >> In the event that the primary server fails, the following is performed to failover to the HS server: >> • Add primary server IP as virtual IP on HS server e.g. ifconfig eth1.100:1 172.30.30.1 netmask 255.255.255.0 >> • Update ARP table e.g. arping -q -U -c 3 -I eth1.100 172.30.30.1 >> • Register the SIP Trunk on the HS server >> >> My initial testing seems to work well and I cant find any issues. >> >> Obviously there are some caveats: >> • Don't sync gui.network.conf and Asterisk SIP Trunk config files as they are different on the HS server >> • The virtual IP is not permanent. If the outage is long term, the HS server should be converted into the primary (only a couple of files are different) >> • Unless converted into the primary, any config changes (including dynamic ones) will need to be synced to the primary server when failed back >> • Devstate will not be maintained >> >> Although this solution is not perfect, the ability to run up a new server in minutes remotely is certainly a big plus. >> >> What do you think? Can you see any other issues? >> >> Regards >> Michael Knill Michael http://www.mksolutions.info |