Server Federating- through 6443 or Adaptor with Admin access?

[SzymonPiskula1]

Hello Portal Experts,

I am wondering what is the difference when it comes to Federating a Highly Available AGS Site through their load balancers. For HA Server

-https://<ags-lb-host>:6443/arcgis

OR

-https://<ags-lb-host>/<webadaptor> with Admin access enabled on the web adaptor

Is there any advantage of one over the other (apart from the need to expose admin access?)

For HA Portal

Likewise, when specifying privatePortalURL on one hand it could be 

-https://<ptl-lb-host>:7443/arcgis

OR

-https://<ptl-lb-host>/<webadaptor> with Admin access enabled on the web adaptor

Considering this post:

Portal privatePortalUrl and Federation Admin Url from Cloud Builder deployment 

And the remark around setting of X-Forwarded-Host ,it seems its in some cases to easier to set 

privatePortalUrl to be the same as WebContextURL ?

If I am in a scenario where i expose Admin access on my webadaptors would it still be better to federate over 7443/6443?

[JonathanQuinn]

When setting up an HA Enterprise deployment, the general rule is that you want all communication to go through components that are checking the health of backend servers, like the web adaptor or load balancer. For example, if you have portal machines p1 as primary and p2 as standby, and server machines s1 and s2, you'll federate with an admin URL so in the event that either s1 or s2 is down, the Portals can still communicate with the health machine(s). For the privatePortalURL, it should also be through a component that is checking the health of the Portals. In the event that p1 or p2 goes down, the Servers can still communicate with the Portal machines. The thing you'll need to be careful about is the web adaptor resides on a single IIS instance, which means it's a single point of failure. The benefit of using a commercial load balancer is that it is typically fault tolerant, so there's built-in redundancy. I've heard some users set up a second web adaptor on a second IIS instance and single use DNS as the failover mechanism.

[SzymonPiskula1]

Thank you for your answer Jonathan. Let me clarify on what i am after. In this box where Administrator URL is to be entered:

when federating a server site with a load balancer  <ags-lb-host> in front of it,  which is preferred:

-https://<ags-lb-host>:6443/arcgis

OR

-https://<ags-lb-host>/<webadaptor> with Admin access enabled on the web adaptor

Is there any advantage of one over the other (apart from the need to expose admin access)?

[JonathanQuinn]

Yes, as I mentioned the advantage of using a URL that Portal can use to communicate with BOTH servers is that if one server goes down, Portal can do just that; still communicate with the other server:

Deployment scenarios for a highly available ArcGIS Enterprise—Portal for ArcGIS (10.6) | ArcGIS Ente... 

Take the first example. If you federate Portal with s1, and s1 goes down, it has no way to talk to s2. If you federate through lb, then if s1 or s2 is down, Portal can still communicate with the server site through the healthy machine.

[SzymonPiskula1]

Hi Jonathan, thanks for your answer. My point is not about if or how to use Load Balancer. Its about what _endpoint_ is better to user for the Administrator URL: <lb-host>:6443/arcgis   OR <lb-host>/<webadaptor_with_admin_access> .

Is there significant performance gain when using access via 6443 rather than via webadaptor? Considering I have admin access enabled on the webadaptor and i have choice what to specify as Administrator URL which is better (and how much) ?

What i am concerned about is the extra work and potential issues for the bit around X-Forwarded* settings. 

[JonathanQuinn]

Ah, I see, sorry, I thought you were wondering if there's a difference between federating through the LB for the admin URL or the Server URL.

The only thing to think about there is that the traffic will be balanced at the LB and at the WA, so that could introduce a slight performance impact, but it's likely negligible. An easy way to test this is to federate using lb:6443/arcgis and publish a handful of services and note the average publishing time. Then, update the URL using the Sharing API and then publish the same number of services. You may want to delete the existing services to make sure the environment is as similar as possible.

If you're not interested in web tier authentication, there's typically no use for a web adaptor.