Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

« Previous Version 2 Next »

Atlassian JIRACloud maintenance

JIRACloud undergoes periodic maintenance, which varies by your region:

How JEMHCloud manages Atlassian JIRACloud maintenance

JEMHCloud validates connectivity with your server prior to retrieving messages.

JEMHCloud Maintenance

We use the JEMHCloud blog to announce upcoming upgrades and the completion of them. We try to publish information about upcoming upgrades a few days prior to the weekly maintenance so that you can prepare for them if needed.

To minimise interruption, upgrades are planned for 12:00hrs on Sundays UTC.

About upgrades

For minor updates, we aim to have a fully automated deployment process:

These upgrades are usually complete in a 5 minute window, with a weekly release, gives a technical weekly availability of 99.95%, however we try to beat that with the process:

  1. Updated applications are posted
  2. New nodes are warm booted, increasing the pool, these will be the 'current' versions, takes ~2m to boot, once available they become part of the load balancers group
  3. Existing customer connections will continue to work interactively via JIRACloud nodes, but scheduled jobs will notice the update and not progress further message retrieval, marking themselves as 'stopping' in their healthcheck response
  4. The Loadblancer that fronts all active nodes reacts to nodes marked as 'stopping' via their healthcheck.  After four 'fails' (30S apart, 2m total) the nodes are terminated by the infrastructure and new nodes are created.  At this point interactive sessions may fail, requiring a browser refresh.
  5. Meanwhile the loadbalancer farms new interactive user request to the new nodes.
  6. The new nodes, on launch continue message retrieval for their hosts.
  7. After 3minutes, the 'active' node count is reduced to the operating norm.
  • No labels