Is Load Balancer Health Check Required for a Highly Available Single Site, Multi-Machine ArcGIS Server?

[BenjaminBlackshear]

I have deployed ArcGIS enterprise 10.8.1 and configured it for high availability. Everything is working well so far.

Machine 1 is running portal (primary), server, data store (primary), and 2 web adapters (portal and server)
Machine 2 is running portal (secondary), server, data store (secondary), and 2 web adapters (portal and server)
The two ArcGIS Server installations have been joined and are operating as one site which is federated with the portal using the load balancer url.

In the load balancer (KEMP), currently we only have heath checks configured for the portal machines, is it necessary to configure them for the server machines as well? It is clear from the documentation that this is required for the portals but I cant tell if we need it for the servers or not. I can understand why this would be necessary if the machines were separate sites but does the health check provide any advantage or additional functionality in this case with a single site?

[DavidHoy · Accepted solution]

Hi @BenjaminBlackshear 

There is an excellent post on this topic here that is well worth a read.

https://community.esri.com/community/implementing-arcgis/blog/2020/04/30/planning-load-balancer-conf...

In a nutshell, you need a HealthCheck for each target (VIP) endpoint configured with the Load Balancer. If there are Web Adaptors, you only need to check that the Web Adaptors are available. 
In your setup, with Portal & Server Web Adaptors on the same machine, I guess you have LB set to share all incoming requests to one "target group" with two Machines.
In that case, you only really need a tcp availability health check for the Web Server hosting the two Web Adaptors. You do not need to use the Portal or Server healthCheck REST endpoints. (The Web Adaptors use these behind the scenes).

If you use separate targets for the portal and server Web Adaptors, you could try just simple html checks for the healthCheck addresses. But... this only tells the Load Balancer that the Web Adaptor on that machine is working and that at least one of the portal/server sites is responding ok. The healthCheck endpoints are not always super fast to respond, so allow some more time and a few more retries than you may expect (as per the blog article)

Hope this helps

[JonathanQuinn · Accepted solution]

The main reason why you may want the LB to use the WA health check, (https://wa.domain.com/portal/portaladmin/healthCheck for example), is you make sure that the WA can proxy requests to the Portal or Server. It ensures that the WA's know that they are still registered. They shouldn't unregister themselves, but it provides an additional check to make sure the WAs can still send requests to backend machines.

[BenjaminBlackshear]

thanks yall,

we currently have the LB using the WA health check, (https://wa.domain.com/portal/portaladmin/healthCheck) so it sounds like we are good to go!

@JonathanQuinnto clarify on your point, the only advantage of adding WA server health checks (https://wa.domain.com/server/rest/info/healthCheck) is that it would confirm that the servers had not become unregistered from the WA?

[JonathanQuinn]

Right, exactly.

[SaurabhUpadhyaya]

I have one question 2 arcgis server's linked on load Balancer,  and at the time of federation given the load balancer url for service and which url we need to give for administration bcoz both are different and pls suggest how to do this?

@BenjaminBlackshear @DavidHoy @JonathanQuinn 

[DavidHoy]

When federating from the Portal’s “Servers” page, you are asked to supply two.URLs :

service URL and administrative URL

in most cases (as per the blog document) these can be the same. It is the route via the Load Balancer, including the “context”.

[DavidHoy]

But…. Before federating - Be sure you have your Portal and Server site configured correctly to use the Load Balancer - with webContextURL set in system properties for each.  Otherwise you may find you get redirects you don’t expect 

[SaurabhUpadhyaya]

We are deploying ArcGIS Servers(On Premises- Due to Date Security Restriction). Previously we are using Load Balancer to connect both ArcGIS Server and not using any Enterprise Portal. 

Now we have Enterprise Portal and ArcGIS Servers are federated with Portal(Only 1 Portal Server). we are planning to use load balancer and not able to found any esri document/help to add the load balancer.

2 ArcGIS Servers

1 Portal

1 Load Balancer

1 Postgres DB Request to all of you please suggest 

[DavidHoy]

The documentation in this link re load  balancers should have all the info you need.

i would be adding your Portal as a target group (backend pool) behind your load balancer - just with a single node in the “portal” pool. This way the load balancer is just acting as a reverse proxy for your portal. 

you haven’t said whether you are using web adaptors or what type of load balancer, so hard to be specific. 
the advantage of using the same LB for portal and server is that you will have one front end FQDN in the URLs for both the portal and the server site. If using WAs, it is trivial to identify which incoming requests should be directed to the portal backend (https://yourdnsname/portal/*) and which should go to the server (https://yourdnsname/arcgis if your server’s VMs are using WAs called “arcgis”.

if not using WAs it is a trickier set of rules to look for in the incoming request (arcgis /home, /arcgis/sharing, /arcgis/portaladmin as a starter set)