• State Suggested Answer
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 61 subscribers
  • Views 666 views
  • Users 0 members are here
Options
Related

High Availability Configuration

graziano santucci
10 months ago

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.

  • 0 9 months ago

    Hello, graziano.

    Indeed, Active Roles does support - and recommend as "Best Practice" - that you should always have at least two AR servers to eliminate single-point-of-failure. You could also use a DNS alias to connect to your AR servers, allowing you the opportunity to manage which server(s) the DNS alias resolves to. In some cases, customers may also opt to use a load-balancer or similar device to manage that DNS alias automatically, which would allow you to do things like load-balance by alternating which server the alias resolves to, and automatically remove servers from the resolution pool if they become unavailable.

    In turn, these servers should/can be connected to some kind of highly-available SQL infrastructure: cluster (most common), replicated, mirrored, or cloud-hosted.

    Hope that helps?

    Shawn

  • 0 9 months ago

    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).