Highly available Portal and federated ArcGIS Server

2524
14
Jump to solution
07-20-2017 11:25 AM
AzinSharaf
Occasional Contributor II

Since we are interested in IWA with a highly available federated ArcGIS Server and Portal (See diagram below), does the federated ArcGIS Server need web adaptor?

In Esri’s diagram ArcGIS Server doesn’t have web adaptor so I assume:
- If users connect via Portal, they should pass Portal web adaptor (wa1 and wa2).
- Third party web applications can connect to GIS services on ArcGIS Server only via 6080 or 6443, so how IWA works here when we don’t have web adaptor on ArcGIS Server?

0 Kudos
1 Solution

Accepted Solutions
JonathanQuinn
Esri Notable Contributor

The federated ArcGIS Server doesn't need the Web Adaptor as it's not necessary.  Since all of the security is controlled in Portal and you're using IWA for the security, the web adaptors are only required for Portal.  If users connect to the Portal, they should use the load balancer, (lb), that sits in front of the two web adaptors.  They shouldn't connect directly to the web adaptors.  Third party web applications or any other client should connect to the server through the load balancer as well.  The idea is that the load balancer will have rules to dictate where the request will go.  For example, https://lb.esri.com/portal will be sent to the two web adaptors and then from there to the portals and https://lb.esri.com/server will be sent to the two servers.

View solution in original post

14 Replies
JonathanQuinn
Esri Notable Contributor

The federated ArcGIS Server doesn't need the Web Adaptor as it's not necessary.  Since all of the security is controlled in Portal and you're using IWA for the security, the web adaptors are only required for Portal.  If users connect to the Portal, they should use the load balancer, (lb), that sits in front of the two web adaptors.  They shouldn't connect directly to the web adaptors.  Third party web applications or any other client should connect to the server through the load balancer as well.  The idea is that the load balancer will have rules to dictate where the request will go.  For example, https://lb.esri.com/portal will be sent to the two web adaptors and then from there to the portals and https://lb.esri.com/server will be sent to the two servers.

AzinSharaf
Occasional Contributor II

Thanks Jonathan for the clear answer.

0 Kudos
AzinSharaf
Occasional Contributor II

Jonathan Quinn

If I install the Portal Web Adaptor on Portal machine (wa1 on p1 & wa2 on p2), does it have a negative impact on High Availability? I am trying to reduce the number of VMs without negative impact. 

0 Kudos
JonathanQuinn
Esri Notable Contributor

One can argue that the more machines you have, the more opportunities there are for one machine to fail.  A lot of the automated cloud deployments put all components on two machines, (web adaptor, portal, server, and data store on each).  The main idea is that you have more than one of each component, so I understand both arguments of having a component on each machine vs two machines with all components on them.  If reducing the number of machines is important, I think you'll be OK with two machines.

PayneRingling
New Contributor III

If I were to add an ArcGIS Server site that was specifically for Enterprise SDE databases, which has 2 ArcGIS Server machines, would I need a Web Adaptor in-front of them before federating them to the portal site, so the Load Balancer sends the request to the Web Adaptor which round-robins between the two ArcGIS Server Machines, or would the rules be applied at the Load Balancer, rendering the Web Adaptor obsolete for SDE sourced ArcGIS Servers as well as the hosted ArcGIS Server machines? 

Could we just register our SDE data sources with the hosting ArcGIS Servers already deployed in this scenario and avoid the whole need for a second ArcGIS Server site specifically for SDE data? 

Also, would the standard Windows Network Load Balancer be sufficient for this scenario, or should we consider a 3rd party?

Sorry for the many questions... 

Thanks!

0 Kudos
JonathanQuinn
Esri Notable Contributor

No problem, Payne!

You can just send traffic from your load balancer to the Server's directly without going through the web adaptor, as that's just adding an unnecessary extra jump.

Yes, you can also just publish directly to the hosting server, that's no problem. Sometimes people/organizations like to have some separation of responsibilities, so the hosting server is solely for hosted data while another federated server is for traditional map services, but there's no problem with publishing traditional map services. This is somewhat related to licenses, as well, so perhaps it's best to reach out to your account manager to ask those types of questions.

Windows NLB will be sufficient, yes, but you need ARR as well to add the X-Forwarded-Host header and health check the servers.

Richard Marr's Blog - Overview of Application Request Routing’s Health Check features 

0 Kudos
PayneRingling
New Contributor III

Excellent, thank you! We will likely keep our server sites separate as you've described, I was just curious if in theory that would work. 

Thanks for the reference to the blog, that is helpful. We will probably go with Windows NLB as that is readily licensed to us. Do you know if ESRI has any NLB that they specifically recommend or are known to perform well with? A lot of documentation just says "a third party load balancer".

Thanks again

0 Kudos
JonathanQuinn
Esri Notable Contributor

ESRI wouldn't really offer any recommendations unless you want some sort of consultant engagement, as there are a lot of variables and questions to answer. At minimum, the LB needs to check the health of the backend machines, (whether that's Portal or Server), and be able to set the X-Forwarded-Host header. That's just about it. It'd only be load balancing HTTP requests, so the performance with our software would be similar to the performance for any other application using http requests.

0 Kudos
PayneRingling
New Contributor III

That's what I figured, thanks!

0 Kudos