Does this Enterprise deployment look correct?

Nryan

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!

LavanyaVasudevanNES

NRyan,

The server does have to connect to the portal via the ports 6443 and 7443. Please make sure it's a two way communication represented in the diagram to understand the scenario better. The Server connects to the DB and the DB connection is validated via the server manager. I sure hope the machines are fairly robust since you are combining the components into two machines.

A really good reference website is the architecture.arcgis.com website. I would also explore this video: ArcGIS Online - Esri Videos: GIS, Events, ArcGIS Products & Industries

Good luck

Nryan

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

DEWright_CA

A Federated Server use both the direct connection on port 6443 and the connection via the web-adaptor. You will also find in your Server and Portal logs that the Server will also query on 6080 for non-authenticated interfaces; so be aware of this aspect as well.

In general your architecture is very sound; as @LavanyaVasudevanNES noted you do need to ensure you have bi-directional communications available but overall your platform is sound.

Nryan

(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

TimoT

Hi @Nryan

Some questions and comments for you.

1. Web Adaptors

Do 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.

2. Portal and Federated Server communication

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

This mainly depends on how you configure the privatePortalURL and Administration URL. For example, if these are set to use your reverse proxy URLs, the Portal and Server won't communicate directly. This impacts flow of traffic and can change which components are involved in TLS handshakes, which could simplify TLS certificate management overall.

privatePortalURL is used by your federated ArcGIS Server sites to reach the Portal
Administration URL is used by Portal to reach federated Server sites

For more information about deployment configurations with and without Web Adaptors, plus info about privatePortalURL and Administration URL, please refer to the document linked below. Even though it focuses on highly available deployments, the guidance and concepts around termination points and Web Adaptor usage still applies to non highly available deployments.

Highly available ArcGIS Enterprise deployment scenarios—Portal for ArcGIS | Documentation for ArcGIS...

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.

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.

5. Machine #4

Assuming 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.

Please don't hesitate to ask any questions - I'll be happy to clarify anything mentioned above. Although, I may be away for a while, so I hope other community members can chime in too.

Nryan

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

1. Web Adaptors
Do 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 #4
Assuming 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. 🙂