Best Practice for ArcGIS Enterprise Multi-Machine Deployment

[cle444]

Hi ArcGIS Enterprise experts,

We are about to start an on-premise multiple-machine deployment (Windows Server). Here is the high-level architecture of the ArcGIS Enterprise part behind the firewall.

1. Web Server (3 x Web Adaptor): 2 CPU - 4GB - C:100GB
2. Portal: 4CPU - 16GB - C:100GB - D:100GB
3. GIS Hosting: 4CPU - 32GB - C:100GB - D:100GB
4. GIS General: 4CPU - 32GB - C:100GB - D:100GB
5. Data Store: 4CPU - 32GB - C:100GB - D:100GB

The question is around hardware resource planning. What is the best practice in terms of:

1. Proper disk size for each of the boxes above? e.g. I can find the minimum requirements from documentation say 10GB spare size. But what is the optimal size for such deployment? What's the factor of planning disk size? What contributes to file size growth?

2. Installation location. Installation on the system drive i.e. C drive? Is it recommended to install ArcGIS to a different drive than C Drive? If so, what's the major benefit of putting the ArcGIS installation to a different drive?

Thanks for the help.

[AngusHooper1]

Your GIS architecture looks fine.

However, we hope to disable the REST API web interface and Service Admin API if accessed externally. Is this achievable with the above setup?

If you want this accessible internally but not externally then you will need to handle this via your external load balancer.

Also, if removing the dedicated web adaptor tier and installing the 3 x web adaptor on the Portal Server as you would normally do, I can see the benefit of resource-saving. Is there any other benefit from doing that?

Installing 3 x web adaptors onto the Portal VM is not normal. Typical deployments have the web adaptor installed on each components VM. In your architecture you would have the WA installed on the portal server, hosting and general server.

The only consideration I would throw into the mix here is defining DNS alias' now. It's quite frustrating to remediate legacy data services that use old fully qualified domain names and not a more agile alias.

[DavidHoy · Accepted solution]

the Trust website provides this paper "ArcGIS Enterprise Web Application Filter Rules"

that lists a suggested list of endpoints that can be blocked to external access - you can apply these rules at the External Load Balancer in your proposed layout.

Angus's comment about where the web adaptors sit is valid - but running all WA's on Portal tier also works - and allows you to remove the need for an internal Load Balancer - you can have the SSL cert on the IIS site hosting the WA's.

unless in future you are planning to add additional virtual machine at Portal tier to provide High Availability?

[cle444]

Great, thanks for the filter rule doc. I am leaning towards separating the WA out just for the stated reasons. HA is not required and unlikely we will go HA in the near future. The only possible scenario is we might add extra server roles in the future.

[DavidHoy]

well - your Web Adaptor will handle it when you add any additional machine to either of your Server sites - you still wont need an internal Load Balancer - really just adding (marginal) latency to every request.

Adding an additional server to provide an additional Role (Image, Notebook etc) also managed with adding a new Web Adaptor on whichever tier you decide to use.

[cle444]

Hi @DavidHoy I am looking at the Web Application Filter rules attached in your previous reply. The list is reasonably long. I wonder if I just merge all those into three rules and what possible bad impact:

.*\/arcgis\/manager.*

.*\/portaladmin\/.*

.*\/admin\/.*

Thanks.

[DavidHoy]

I wouldn't alter the list - it has been put together this way by the Esri Security team to be very specific about what gets blocked. There are some other endpoints that you would block with a less specific rule that may prevent (for example) publishing or overwriting services or sharing Portal items.

[cle444]

Will keep the WA tier seperate. Thanks for suggestion on the DNS alias, we have pretty good naming convention policy here so should be fine.

[MichaelGinzburg]

Hello,



The disk size depends on amount of data you are going to store.

Most contributor to disk growth is the data, especially cached.

Cached layers can be of sizes closed to a terabyte at lower scales like 1:250.

Also, 4Gb of RAM for a web server seems fairly low amount to me.

Regarding installing ArcGIS on disk other than C: - this is rule of thumb for any system on Windows, leaving C: to Windows.

[cle444 · Accepted solution]

Thank you all for your input. I will mark this as solved. To summarise from replies, the good practices are (windows server, 10.8.1 multi-machine on-prem single site non-HA deployment)

1, separate ArcGIS installation to a different drive than OS drive as a general IT practice

2, keep the data/content as close as the ArcGIS server, performance-wise is almost local > cloud share. 

3, disk size vary depending on type and volume of data. Since we are mostly 2D maps with less than 40GB caching, it is safe to start from 100GB dedicated disk size for Portal, GIS and Data Store Server with a monitoring mechanism so they can be adjusted if needed.

4, Configuration store is a single point of failure for single-site deployment so make sure it is accessible all time. We plan to put it on our Azure SMB share.

5, We decide to separate the WA tier for simplicity. But can be dissolved into the existing Portal to save the need for a box running WA.