Select to view content in your preferred language

Need a sanity check on system architecture - implementing Web Adaptors

948
6
Jump to solution
01-19-2024 03:41 PM
tigerwoulds
Occasional Contributor III

I have to opportunity to re-design our ArcGIS Enterprise deployment and could use a sanity check.

Current state: ArcGIS Enterprise on 11.1, Windows, on prem, no web adaptors, F5 for load balancer, Portal and ArcGIS Server in DMZ (for field work use without VPN), other components in internal network

tigerwoulds_0-1705706846088.png

Future state: ArcGIS Enterprise 11.1 windows on prem (no change), new host in DMZ with multiple web adaptors installed, F5 in front of web adaptor host (IT requirement), all AGE components moved to internal network

tigerwoulds_1-1705707477357.png

 

What I think this should achieve is the ability to still connect to Portal off VPN; traffic would route to F5 > Web Adaptor host > Web Adaptor host routes to appropriate AGE servers within the internal network

We currently use the DNS alias to define routes within F5 (eg. portal.company.com/arcgis, server.company.com/arcgis). Ideally, our F5 config could be simplified by having a single VIP (eg. maps.company.com) which routes to the Web Adaptor host > and we use the URL context to define where traffic goes (map.company.com/portal, maps.company.com/server, maps.company.com/image).

Any gaping holes in this plan? Is the single web adaptor host (with web adaptor for portal, server, image server installed) advisable? 

0 Kudos
1 Solution

Accepted Solutions
MichaelJenkins
Occasional Contributor III

I think you nailed it, nice work!  This is almost exactly what we have done and it works great.  No VPN required and high security.   The only thing we did a little different from your plan is that we created a Virtual server in F5 and assigned our DNS name to it.   That way we can offload SSL to F5, and should we ever need to swap servers, we can do so by simply changing what F5 points to for the web adaptor server.  No problems at all running multiple web adaptors on a single server.

 

Edit:  I guess we do subdomains differently than you do.   We have one subdomain for the whole system (enterprise.company.com/portal, enterprise.company.com/server, enterprise.company.com/image, etc).   Each component except the data store has its own web adaptor.

 

GISP

View solution in original post

6 Replies
MichaelJenkins
Occasional Contributor III

I think you nailed it, nice work!  This is almost exactly what we have done and it works great.  No VPN required and high security.   The only thing we did a little different from your plan is that we created a Virtual server in F5 and assigned our DNS name to it.   That way we can offload SSL to F5, and should we ever need to swap servers, we can do so by simply changing what F5 points to for the web adaptor server.  No problems at all running multiple web adaptors on a single server.

 

Edit:  I guess we do subdomains differently than you do.   We have one subdomain for the whole system (enterprise.company.com/portal, enterprise.company.com/server, enterprise.company.com/image, etc).   Each component except the data store has its own web adaptor.

 

GISP
tigerwoulds
Occasional Contributor III

Awesome, appreciate the feedback @MichaelJenkins ! Now I can rest easy 😊  Yes, the goal would be to get our subdomains aligned with what you have: enterprise.company.com/*web-adaptor-name*

Right now it's a big mess in F5 (which I have limited visibility into) with multiple VIPs, pools, iRules just for a standard deployment. I'm hoping we can get to state that pretty much emulates yours!

I'm planning to deploy all this with the PowerShell DSC too, so moving things into our internal network should reduce the # of firewall rules I need to implement. Really, I just need to make sure the Web Adaptor host can communicate with the various AGE components on their designated ports right (7443, 6443, the usual)? Being on the internal network should alleviate some of the headaches with the internal communication between Portal, Servers, and Datastore. At least that's what my Friday night brain is thinking. 

0 Kudos
tigerwoulds
Occasional Contributor III

 That way we can offload SSL to F5, and should we ever need to swap servers, we can do so by simply changing what F5 points to for the web adaptor server.  No problems at all running multiple web adaptors on a single server.

Can you elaborate on this a little bit? So you have your 'Site/VIP' (enterprise.company.com) in F5 using a CA SSL certificate correct? Do you also configure SSL within IIS for each web adaptor using domain or CA certs? What about the portal/arcgis server machines? @MichaelJenkins 

0 Kudos
MichaelJenkins
Occasional Contributor III

Yes, the F5 Virtual Server has the DNS C-Name assigned to its IP and a CA SSL applied to it.  The web adaptor server runs IIS and can use a domain cert.  The F5 VS is the only thing end users connect to.   It proxies traffic to a 'pool' which, in this case, only has one server in it and that is the web adaptor server.

GISP
BillFox
MVP Frequent Contributor

Hello @tigerwoulds ,

Throwing a few items on the table here...

If you are getting the chance for a clean build and have the resources, go for a High Available setup for all of the components (web adaptor(s), portal, arcgis server, ags server for printing, image server for raster analysis, image server for image hosting, image server for dynamic image serving, relational/spatio/tile-cache data stores, raster data stores, monitor, etc.

Are you doing any single-sign on or hybrid sso and portal users, spanning different domains in dmz vs internal, ca signed ssl certs to fit your deployment, Azure Active Directory integrations, private portal url and web context url options, GPS RTK live mobile editing including on-the-fly ortho-metric height in feet captured in the z field (not post processed or some arcade expression) with enterprise?

0 Kudos
JoshuaBixby
MVP Esteemed Contributor

The major issue I see with "deploy it all with high availability" is licensing, all that functionality and uptime will come at a pretty steep cost, especially if it isn't needed to meet business needs.