Does this Enterprise deployment look correct?

Question

Hey everyone! I'm planning on re-deploying our ArcGIS Enterprise system. Currently it is a base deployment and the goal is to make it multi-machine for better performance and control.

I've made a simplified diagram for how the components connect to one another. Ports are not displayed for simplicity. I have 2 questions.

1) When Server is Federated with Portal, does the Server connect directly to portal? Or does Server's Web Adaptor connect directly to Portal?

2) Does rest of diagram appear correct?

Thank you!

Nryan · Answer

(giving same comment from previously reply, since it applies here)

I'm confused on how the ports are configured. In the below diagram, Server speaks directly to Portal (one way) through 7443. And Portal's Web Adaptor speaks directly to Server through 6443 (which is for a Federated Server?).

https://enterprise.arcgis.com/en/portal/11.5/install/windows/pdf/ports-enterprise-deploy-dgm.pdf

Nryan · Answer

I'm confused on how the ports are configured. In the below diagram, Server speaks directly to Portal (one way) through 7443. And Portal's Web Adaptor speaks directly to Server through 6443 (which is for a Federated Server?).

https://enterprise.arcgis.com/en/portal/11.5/install/windows/pdf/ports-enterprise-deploy-dgm.pdf

Nryan · Answer

Thank you so much for the detailed reply! This was extremely helpful. My comments are below.

1. Web AdaptorsDo you require ArcGIS Web Adaptors in your setup? These are typically only necessary if you don’t have a third-party reverse proxy/load balancer or if you need web-tier authentication. If not required, removing them can simplify your architecture and reduce both network and management overhead. In such a setup, your reverse proxy could serve as the TLS termination point for end users and potentially for internal ArcGIS Enterprise traffic as well. More about this in the next point below.

Our reverse proxy is primarily to intercept traffic for the web server and then return the response. Additionally, we will be using SAML authentication. I think we need Web Adaptor for this, but I'll research through the documentation you shared!

2. Portal and Federated Server communication

This makes sense. I'll do further research, thank you!

3. Machine #2 (Monitor, Monitor DB, Portal)Regarding machine #2 in your diagram, just be cautious and aware that each component (Monitor Server, Monitor postgres, Portal for ArcGIS) all have their own system requirements to cater for. With all components on the same machine, there is a risk that resource contention could degrade the performance and reliability of all components involved.

Storage is our biggest cost/limitation. This machine will likely have 8 cpu cores and 32+ gb of memory. It should have enough recourses for both Monitor and Portal. Though if needed, we can easily move Portal to its own machine should performance become an issue.

From research, Monitor Server/Agent needs just 4 cpu cores and 10 gb of memory.

4. Machine #3 (Hosting Server + Relational Data Store)Similarly to above, both Hosting Server and ArcGIS Data Store (assuming this is only relational datastore and not object/tilecache store as well) are both resource intensive components. Whether this setup is viable depends heavily on your expected user load, data complexity, usage patterns, etc.

Correct, the Data Store is a relational data store. We don't have any plans at this time that would require the other data stores. This machine will also have 8 cpu cores and 32+ gb of memory. It should have enough resources for both, but we can split this into separate machines should performance become an issue.

5. Machine #4Assuming the SQL Server is being used as an Enterprise Geodatabase, the data flow should connect to and from the Hosting Server, not the ArcGIS Data Store. Data Stores and data sources are registered with ArcGIS Server, not the ArcGIS Data Store.

Yes, SQL Server is being used to house the Enterprise Geodatabases.  We have only a few, so I expect this to use minimal resources. Monitor Server/Database may get moved to this machine because of this.

Thanks for the flow connection correction, I'll update my diagram! Thanks again for your help. 🙂