That answers my question in that it's probably not worth risking corrupt configuration on the redundant server. The scenario you describe, Scott, would put everything into the upgraded environment all at once which kinda defeats the purpose of testing :-)
Unless I can think of a way to do this I might just tell them it's not possible and that I've already done all the testing I can. 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/
