Hi, I am trying to design High Availability for Appian platform. Currently I hav

I don't know much since I'm not an admin for my team. We spread our single VM instances in dev/test/qa/prod to run on 2 machines each also a year or so ago. We now have 16 engines running on each of the 2 machines with 1 machine a primary and the other the secondary. It seems to work fine and we use a single server alias for the users to connect to (versus the actual computer name) which helps with https certificates, etc. When we made the move we copied 1-2 of the 3 large .kdb files for the execution engines to the new box so that it could better spread the load and large (40+gb) memory usage of our server over 2 machines. It took a while for new incoming processes to balance out over the 6 engines (3 per box) with older processes completing and eventually auto archiving/deleting.

Load & performance wise this has been an improvement for us since we now have 2x the analytics engines, etc. However, I don't think it has really helped from an uptime/availability perspective. Generally speaking both machines have to be fully operational at all times for Appian to be responsive. Users are unable to connect to machine 1 for half of a transaction and 2 for the other half, as far as I know our load balancing system with the alias creates sticky sessions. However, per the docs, when a process model kicks off a subprocess the subprocess runs on the same engine (versus a random engine if a JMS send/receive message node starts a new process). By moving to 2 machines and 6 execution engines there is less delay when processes spawn subprocesses because in theory only half of the business users are on each server and so the potential queue length on those engines is shorter. From a users perspective they connect to the alias in their browser and never know (nor do I) which server or engines they are on.

RAM usage is lower on both servers (which are Win 2008 R2 guests in a VM) which makes our data center people happier. 2 servers with additional patching requirements and configuration issues has gotten a bit more complicated as well as our disaster recovery testing, log file analysis, etc. I don't know how the errors are tracked between the log files, I assume that all errors are on both servers since I only look at them on the primary when necessary. We run 1 MS SQL 2008 database and both servers connect to it. I can't comment on how adding new datasources is done (i.e does an admin have to add it to a config file on each machine).

So far as a developer with minimal need to be an admin and only semi-annual DR drills the dual server setups haven't been a problem. I import my application exports into the test/qa/prod servers only 1 time and Appian is smart enough to apply them to both systems.

I don't know much since I'm not an admin for my team. We spread our single VM instances in dev/test/qa/prod to run on 2 machines each also a year or so ago. We now have 16 engines running on each of the 2 machines with 1 machine a primary and the other the secondary. It seems to work fine and we use a single server alias for the users to connect to (versus the actual computer name) which helps with https certificates, etc. When we made the move we copied 1-2 of the 3 large .kdb files for the execution engines to the new box so that it could better spread the load and large (40+gb) memory usage of our server over 2 machines. It took a while for new incoming processes to balance out over the 6 engines (3 per box) with older processes completing and eventually auto archiving/deleting.

Load & performance wise this has been an improvement for us since we now have 2x the analytics engines, etc. However, I don't think it has really helped from an uptime/availability perspective. Generally speaking both machines have to be fully operational at all times for Appian to be responsive. Users are unable to connect to machine 1 for half of a transaction and 2 for the other half, as far as I know our load balancing system with the alias creates sticky sessions. However, per the docs, when a process model kicks off a subprocess the subprocess runs on the same engine (versus a random engine if a JMS send/receive message node starts a new process). By moving to 2 machines and 6 execution engines there is less delay when processes spawn subprocesses because in theory only half of the business users are on each server and so the potential queue length on those engines is shorter. From a users perspective they connect to the alias in their browser and never know (nor do I) which server or engines they are on.

RAM usage is lower on both servers (which are Win 2008 R2 guests in a VM) which makes our data center people happier. 2 servers with additional patching requirements and configuration issues has gotten a bit more complicated as well as our disaster recovery testing, log file analysis, etc. I don't know how the errors are tracked between the log files, I assume that all errors are on both servers since I only look at them on the primary when necessary. We run 1 MS SQL 2008 database and both servers connect to it. I can't comment on how adding new datasources is done (i.e does an admin have to add it to a config file on each machine).

So far as a developer with minimal need to be an admin and only semi-annual DR drills the dual server setups haven't been a problem. I import my application exports into the test/qa/prod servers only 1 time and Appian is smart enough to apply them to both systems.