Upgrade strategy

RE: Upgrade strategy

Umesh Patel — Thu, 20 Sep 2018 15:15:27 GMT

You are right Eliot. This is not supported at this time. We can reduce down time only while upgrade.

RE: Upgrade strategy

Eliot Gerson — Thu, 20 Sep 2018 14:59:17 GMT

This is not correct. Please do not do this. You cannot upgrade just one node at a time.

In terms of the original post, if your question is whether you can minimize downtime by prepping the new install before stopping the existing install, the answer is yes. But if the question is whether it's possible to do an upgrade without any downtime at all, the answer is no. Completely stopping the server and creating a full backup is a required part of the upgrade. We understand and share the desire for outageless upgrades, and it is something that we are working towards. But it is not something that is supported at this time.

RE: Upgrade strategy

Robert Shankin — Wed, 19 Sep 2018 16:32:00 GMT

I've not seen HA considered as a direct factor in the upgrade process.

Sometimes, what we see is an upgrade environment - essentially a mirror of production that you upgrade first. Your stakeholders and testers should test their applications in the upgrade environment and once everyone is satisfied, and understands behavior changes, Production is upgraded.

There's a few details in the Playbook that might help you:

RE: Upgrade strategy

chandu — Wed, 19 Sep 2018 13:24:40 GMT

We always prefer to go with 1st option, we use to communicate the business regarding the downtime and impacting applications during down time for upgrade.
The implementation purpose the Option 2 is good subject to condition that Business will run 24/7. You can work with Appian Support so that they can provide you the good solution as per your Support case.

RE: Upgrade strategy

himanshun — Wed, 19 Sep 2018 09:53:35 GMT

Hi Jesusa310,

While upgrading to new Appian environment, you will need new licenses as well.
It is always best approach to have a defined downtime and then perform environment maintenance/ upgrade activities.
Option 1 will ensure there are no new activities performed while the upgrade is in progress and by this you reduce the avenues of business data loss.
with Option 2, you potentially might be creating two different url's for the application which might raise confusion from business users. An alternative will be to install a parallel server and make the same available to users and maintain the original server as a backup till the new server is smooth functioning.

RE: Upgrade strategy

sagarl511 — Wed, 19 Sep 2018 08:26:07 GMT

To setup high availability system - you can go through below links -

docs.appian.com/.../How_to_Set_Up_High_Availability_Installations.html
docs.appian.com/.../High_Availability_and_Distributed_Installations.html

Above links will help you in setting up another node in cluster.

You might need to shut down existing server to setup topology.xml for setting up high availability system.

Based on your comments, it seems like your server is not configured for high availability as you might have only specific business hours where customers use the system. I would suggest you to schedule upgrade in non business hours.

RE: Upgrade strategy

jesusa310 — Tue, 18 Sep 2018 19:40:06 GMT

Hi Umeshp, thanks for your answer. We dont have high availability in place, we only have one standalone server, but there is a thought that we could keep the service up during the upgrade time by installing a second appian server that would be up while the other server is being upgraded and maintaining two parallel and independent appian environments. I dont think this is the recommended way to do to the upgrade but I wanted to ask the community for thoughts.

RE: Upgrade strategy

Umesh Patel — Tue, 18 Sep 2018 18:07:35 GMT

Hi,

If you are upgrading to 18.3 version, there are some major changes in architecture. There is no Application server requirement. You need to check your topology before starting upgrade. Better to discuss with Appian Support for more clarity.

Edited Response : Upgrade of one instance at a time is not supported at this time. Better to have approach to reduce down time.

Thanks