Doug, This is a multi-topic question.
There are different pieces of the system and there are different requirements for approaching updating with zero down time. Mid-tier Just do the upgrade/patch/whatever on them one at a time. There is no issue with mixed versions. The big issue here is that if you take down a mid-tier, you can cause a user to have to relogin if they are connected to that mid-tier. You can eliminate that by bringing up new mid-tiers, pointing load balancer to the new ones and off the old ones, then a day later, remove the old ones (by then, people have rolled off them to the new ones). If use VMs for your mid-tiers, this is a temporary set of additional VMs. If you don't want that, just upgrade each in place and roll across them. NO down-time, but users may need to relogin as the mid-tier they were connected to goes down. And, they may be bumped a couple of times if they get redirected to one that is still awaiting upgrade. AR Server/CMDB We have customers upgrading/patching here today with zero down time. We are going to be writing up a more formal document about this topic over the next few months, but we do know it works. The key here is to take each server one at a time and upgrade. There is no state in the server so no problem with having users redirect to other servers as one is down. You can just go cowboy and upgrade one at a time and roll across or invest a bit more and be orderly. Something like For each server: - Take out of the load balancer - Take out of the server group (this stops it from signaling other servers to recache) - Upgrade/patch/whatever - Put back in the server group - Put back in the load balancer This gives you a rolling upgrade where you upgrade each server one at a time with other servers still active. The one downside is that if a server not upgraded yet goes down for some reason during this process, if it is an upgrade, it will not come up until it is upgraded (if being patched, it will come up without issue). This is because the version stamp of the DB has been changed. But, this is unusual, it still doesn't take down other servers, and we are talking about a short time window - 1 hour or so for the first server upgrade (much less for patches), and 15 minutes for other than the first server upgrade (much less for patches). We are going to formally document a set of steps to cover all bases, but this is the idea. For patches, this is especially easy and straight-forward as there are not major changes being made to the system. Applications Upgades are not possible with zero-down time. Someone has noted a feature that is on the Communities Ideas list around this. We have a POC for this capability, it just has not made a release train at this point. We can help minimize the outage time. BUT, for patches..... There is generally very controlled change to specific workflow items and maybe some fields and the like. There is definitely a clean way to upgrade without downtime. Just install the patch on the first server with the signaling of other servers turned off. When done, if the patch is all definitions (no executables, you can simply signal each other server one at a time (to avoid all going to the database simultaneously for new defs) and get the updates. If there is an executable, just then run the patch on each secondary server and as you do that, if it doesn't recache definitions, tell it to as you are installing the patch. This is not a definitive list of steps, just a conceptual overview, but we have quite a few customers using the types of techniques above to do live system updates. It does work. PLEASE OF COURSE install the patches and hotfixes in dev and test first and make sure all is working as expected and then upgrade production using the ideas above.... And OF COURSE, make sure you have recent backups - just in case. Doug Mueller From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Hynes, Douglas Sent: Monday, April 20, 2015 8:57 AM To: arslist@ARSLIST.ORG Subject: ARS Patching Question ** All, Anyone ever come up with an idea for in-place ARS upgrades/patching? Something like using dual server groups so the system never has to go down during maintenance? (if that's even possible) I'm trying to come up with a way to decrease needed downtimes to handle the patch/upgrade load. (and reduce the need for me to be here during typical downtime window from 22:00-05:00). Ideas? Thanks, -Doug [cid:image001.jpg@01D07C1C.A0119620] Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
