High Availability Configuration

Hello everyone,

I wanted to know if there is a configuration mode for achieving high availability in case of server failure. For instance, is it possible to set up a configuration like a farm with multiple servers using the same database?

Thank you and regards.

Parents
  • My experience / recommendation is as follows:

    For the AR Web Site servers - most customers will have at least two of these behind an F5 load balancer.  The web sites themselves should be configured to find the "next available" Admin server based on the service connection points (SCPs) published to AD by the Active Roles admin services.  The "trick" though with the SCPs is that they are managed by the AR admin service itself (a service publishes its SCP when it comes up and removes it when it stops in an orderly fashion).  If an AR server stops suddenly, then it won't remove its SCP.  I recommend using application monitoring (for example, SolarWinds) to watch your AR servers and if one goes down without removing its SCP, that the monitoring software be configured to cleanup the SCP for the downed server.

    For the admin services themselves, I would recommend having at least two in an active-active (always running) setup.  If you have a large environment where you use a lot scheduled tasks and/or workflows, you may want to have at least one additional server dedicated to executing those.  As I noted above, put your AR admin services under monitoring by whatever application monitoring platform you use.

    For the SQL backend, you want a high performance SQL cluster and operate your servers in a "shared database" configuration (not replicated - that is a major nuisance when it comes to doing upgrades).

Reply
  • My experience / recommendation is as follows:

    For the AR Web Site servers - most customers will have at least two of these behind an F5 load balancer.  The web sites themselves should be configured to find the "next available" Admin server based on the service connection points (SCPs) published to AD by the Active Roles admin services.  The "trick" though with the SCPs is that they are managed by the AR admin service itself (a service publishes its SCP when it comes up and removes it when it stops in an orderly fashion).  If an AR server stops suddenly, then it won't remove its SCP.  I recommend using application monitoring (for example, SolarWinds) to watch your AR servers and if one goes down without removing its SCP, that the monitoring software be configured to cleanup the SCP for the downed server.

    For the admin services themselves, I would recommend having at least two in an active-active (always running) setup.  If you have a large environment where you use a lot scheduled tasks and/or workflows, you may want to have at least one additional server dedicated to executing those.  As I noted above, put your AR admin services under monitoring by whatever application monitoring platform you use.

    For the SQL backend, you want a high performance SQL cluster and operate your servers in a "shared database" configuration (not replicated - that is a major nuisance when it comes to doing upgrades).

Children
No Data