<div>Does a reboot for the upgrade to switch from the inactive partition to the active partion take longer than 15 minutes?</div>
<div> </div>
<div>What I would do:</div>
<div>1. Run the upgrade without a reboot or switching versions </div>
<div>2. During my outage window switch versions and reboot</div>
<div>---at this point your system is functioning on the old hardware</div>
<div>3. Take a DRS backup for restore to the new cluster</div>
<div>4. Restore to new cluster</div>
<div>5. Switch TFTP settings</div>
<div>--may need to reduce your DHCP lease time</div>
<div>6. Reset all devices/point gateways to new cluster</div>
<div>---at this point you are usig the new hardware</div>
<div> </div>
<div>I'd imagine there would be less than 15 minutes downtime with this procedure but I've not done a bridged upgrade with 8.6 yet<br><br></div>
<div class="gmail_quote">On Mon, Feb 27, 2012 at 10:55 AM, Beck, Andre <span dir="ltr"><<a href="mailto:cisco-voip@ibh.net">cisco-voip@ibh.net</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">Hi,<br><br>I'm preparing for an upgrade of a cluster (just one sub) running 7.1(3)<br>on DL380G4s (7845H2) to 8.6(2) on DL380G6s. To make things interesting,<br>
the old version doesn't even recognize the new servers, and the new version<br>is not supported on the old metal except for bridge upgrade. Needless to<br>say, the upgrade has to be done with minimal downtime, something like<br>
15min to switch would be acceptable, not more.<br><br>I'm planning to proceed as such:<br><br>1) Shut down the pub, while the sub continues serving the live network.<br>2) Boot the pub using GRML or such Linux live CD and make a full disk<br>
copy to external storage. Maybe also break the mirrors and insert<br> additional disks to have a physical copy through RAID, putting the<br> original disks at a safe place.<br>3) Isolate the pub in a replica of the original network including<br>
default gateway, DNS and NTP servers as needed. Boot it up again.<br>4) Do the upgrade procedure to 8.6(2) as documented, ending up with<br> a bridged upgrade only machine.<br> *** Here the docs state I have to also do this to the sub(s). Of<br>
course I can't, they are serving the live network here. Is this<br> fatal, or is my procedure a proper workaround?<br>5) Do a DRS backup of the bridge-upgraded pub.<br>6) Restore the original pub using the copies made in step (2), plug it<br>
back into the live network, boot it up and have the live network<br> working fully redundant again.<br>7) Install 8.6(2) on a new DL380G6 plugged into the replica network.<br>8) Restore the DRS backup from (5) to this new pub.<br>
9) Make sure the pub is working correctly, except for the missing sub.<br>10) Now add a second DL380G6 to the replica network, install 8.6(2) as<br> a sub on it, and reestablish the cluster. Manually make sure all<br> files in the TFTP server of the original sub are available on the<br>
new sub as well, as that one isn't restored from backup.<br>11) After making a lot of tests and sanity checks, swap in the new<br> cluster in a short downtime window.<br><br>Does this plan make any sense? Is there a better one? I'm specifically<br>
bothered by the documented need to perform the bridged upgrade on all<br>nodes in unison, and then to restore first to the pub, then to all the<br>subs. Of course that's impossible without inacceptable downtimes. But<br>
I assume that I cannot, after step (6), just isolate the old sub in<br>the same way as the pub before, doing a bridge upgrade of that isolated<br>sub only to get hold of a DRS backup of the sub?<br><br>Any hints or ideas welcome,<br>
TIA,<br>Andre.<br><span class="HOEnZb"><font color="#888888">--<br> Cool .signatures are so 90s...<br><br>-> Andre Beck +++ ABP-RIPE +++ IBH IT-Service GmbH, Dresden <-<br>_______________________________________________<br>
cisco-voip mailing list<br><a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br><a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
</font></span></blockquote></div><br>