Makes me ask myself if a HA upgrade should have a special bootup script/procedure to prevent the profile push but allow for a certificate handshake/sunc to the other server before assuming any interactive roles with users/gateway. ============================ Tony Graziano, Manager Telephone: 434.984.8430 Fax: 434.984.8431
Email: tgrazi...@myitdepartment.net LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 Fax: 434.984.8427 Helpdesk Contract Customers: http://www.myitdepartment.net/gethelp/ ----- Original Message ----- From: sipx-users-boun...@list.sipfoundry.org <sipx-users-boun...@list.sipfoundry.org> Cc: sipx-users@list.sipfoundry.org <sipx-users@list.sipfoundry.org> Sent: Thu Apr 29 19:27:05 2010 Subject: Re: [sipx-users] Mock upgrade test with mismatched sipX versions Perhaps what I'll do is reboot all the phones and while they're rebooting I'll swap the servers out. sounds like a plan, ehh? Josh Patten Assistant Network Administrator Brazos County IT Dept. (979) 361-4676 On 4/29/2010 6:26 PM, Tony Graziano wrote: > And if you do an upgrade and the server comes back online, would it matter > since it will oush profiles and send reboot messages to the phones? > ============================ > Tony Graziano, Manager > Telephone: 434.984.8430 > Fax: 434.984.8431 > > Email: tgrazi...@myitdepartment.net > > LAN/Telephony/Security and Control Systems Helpdesk: > Telephone: 434.984.8426 > Fax: 434.984.8427 > > Helpdesk Contract Customers: > http://www.myitdepartment.net/gethelp/ > > ----- Original Message ----- > From: sipx-users-boun...@list.sipfoundry.org > <sipx-users-boun...@list.sipfoundry.org> > Cc: sipx-users@list.sipfoundry.org<sipx-users@list.sipfoundry.org> > Sent: Thu Apr 29 19:02:10 2010 > Subject: Re: [sipx-users] Mock upgrade test with mismatched sipX versions > > Now that I reread your post Scott, it make much more sense, and this is > what we ultimately decided to do. One question that may or may not be > worth asking, is there an easy way to "copy" registrations over so that > the mock upgrade system will immediately have all registrations so > actually "downtime" will be minimal? > > Josh Patten > Assistant Network Administrator > Brazos County IT Dept. > (979) 361-4676 > > > On 4/29/2010 3:18 PM, Scott Lawrence wrote: > >> On Thu, 2010-04-29 at 14:51 -0500, Josh Patten wrote: >> >> >>> Already did those things you recommended with the "First Test System". >>> That doesn't "mirror" my current production environment. It only makes >>> a separate environment that I can play around in. >>> >>> What I need to be able to do is have an exact replica of my 4.0.4 >>> production environment installed and upgraded to 4.2 on a separate >>> server, then dropped in place of the production system for about a >>> half hour so I can do extensive testing on a 4.2 system that mimics >>> our configuration while not causing basic calling on the redundant >>> proxy and all phones connected to it to go down. I just need to make >>> sure that If I have the redundant proxy running 4.0.4 and the replica >>> of the main production server running 4.2 that I won't see any >>> problems when I unplug the replica 4.2 server and put the 4.0.4 main >>> production server back in place. >>> >>> I know this sounds redundant and unnecessary and quite possibly >>> confusing but this is the only way I can think of that will not cause >>> any downtime for basic calling to users, and allow me to do FULL 4.2 >>> testing. >>> >>> >> There are at least two tricky things about the test you describe >> (upgrading only one of an HA pair and then testing it): >> >> * Unless you _very_ carefully analyze where the packets went in >> your test calls, the one you upgraded could be badly broken and >> the fact that you have the old one still there in HA mode could >> cause all the calls to work anyway. >> * The upgraded master will try to reconfigure the distributed >> server, but that configuration won't take because the software >> version won't match (but the configuration could be corrupted >> such that on reboot the service won't come up - only bringing >> the original master back and pushing profiles will fix it). >> >> What you really want to do is create an entire HA pair of new systems by >> cloning your existing servers onto them with the old software, then >> upgrade the clones, then at some safe time swap the clones bringing all >> the old servers off line. Test the clones, and when you've satisfied >> yourself that they work, do the upgrade on the originals and swap them >> back in. If you have spare hardware, you can just use the clones and >> repurpose the originals; if not, you can use VMs to create the clones >> and you end up doing the upgrades twice. >> >> >> >> > _______________________________________________ > sipx-users mailing list sipx-users@list.sipfoundry.org > List Archive: http://list.sipfoundry.org/archive/sipx-users > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users > sipXecs IP PBX -- http://www.sipfoundry.org/ > _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/ _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
