2

We're looking at setting up ArcGIS Server with Postgres for the RDBMS. We have two machines, one aging and a new hotness. What is the best implementation strategy with these resources? Should we put both Server and Postgres on the new machine, put both on both machines, Server on new and Postgres on old, Postgres on new Server on old? ...or something else entirely?

Old and not yet busted:

Year: 2008  
CPU: 2x Dual-core Opteron 2.8GHz  
RAM: 64GB   
Network: 2x 1Gbps  
Storage: 1.3TB in RAID 5 (6x 280GB 15K rpm serial SCSI)  
OS: Windows Server 2003 x64 (upgrade to Server 2012 planned)

New hotness:

Year: 2014
CPU: 1x 8-core @2Ghz (Xeon E5-2640 v2)
RAM: 16GB (2x 8GB 1600Mhz DDR3L)
Network: 2x 1Gbps
Storage: 3.6TB in RAID 5+0 (6x 900GB 10k rpm serial scsi)*
OS: Windows Server 2012 x64

Storage: this is projected and open to change, we haven't purchased the drives yet.

File resources which will be put into the RDBMS. Expected data growth rate: 15%/yr (but really, we have no idea):

File-gdb:   15gb
Rasters:  1000gb (includes overviews)

Internal users, same subnet, mostly gigabit:

  • 6 to 10 active daily use ArcGIS Desktop users drawing from the data, mostly read operations, pulling from the central repository for base maps and shared data, adding their own stuff from elsewhere.

  • 2 to 3 data editors, but this happens rarely, once a week perhaps.

  • 25-50 readers, currently using ArcReader but looking to migrate to web maps (a major reason we're implementing ArcGIS Server to begin with).

Projected purpose of ArcGIS Server + RDBMS:

  • primary daily use warehouse for the users mentioned above
  • Master server for geodatabase replication to district offices
  • development and learning area for web maps and services which will eventually be migrated to outside firewall for public consumption (which is ArcGIS Server + Oracle)
  • (ArcGIS Portal?)

We have whatever licenses for ArcGIS Server needed (from Basic to Enterprise Advanced), but not for Oracle or SQL Server, hence the Postgres for RDBMS specification.

There is no Sys Admin IT or DBA staff to dedicate to setting up and maintaining these machines and services, that will be handled by a GIS person who still needs to allocate most of his/her time to regular ol' GIS. (guess who?) This is a preface to saying the solution that makes best use of the hard and software is not necessarily the optimal solution, please keep administrative overhead in mind.

  • Sounds like the 'old' machine can handle being a Dev machine... So personally I'd be tempted to go for gold on NewHotness and put it all on there... but build it on Old and deploy it on NewHotness... you could probably even run some VM's on NewHotness and use those as Dev 'boxes' too...!!! If you've got that much power, could you even set up multiple PostgreSQL databases on that box and use those as DEV, QA and Prod SDE databases (if you need...)? Will you have a web server installed on here too? Be sure to keep lots of Tim Horton's on hand...and good luck! – DPSSpatial Jun 25 '14 at 18:19
  • 1
    If I'm reading that right, the "new hotness" has slower CPU (though more of them), slower disk, and less RAM. – Vince Jun 25 '14 at 18:20
  • yes @Vince, by the numbers new hotness has lower CPU megahertz, but the chip is several generations newer and has on board cache and some other stuff I don't understand. I was unable to find a (clear) report which could tell me which is in fact faster in the real world. The physical drives are slower, but the backplane is faster; I dunno what the limiting factor is/are. RAM is a bit of a canard, since it's the easiest and cheapest thing to attack (if we find ourselves constrained there we can change it quickly). – matt wilkie Jun 25 '14 at 18:27
  • 1
    16Mb v 64Mb won't make a huge difference in AGS operation, but it could significantly impact a database; I believe 8 CPU cores kicks you into the next license class in ArcGIS. You may have to benchmark performance of each in real-world conditions before determining what to do. – Vince Jun 25 '14 at 19:11
3

One thing I've learned over the years is that there isn't a "right" architecture but there are bad one.

In your case, decisions have already been made for you in regards to hardware/resources, which as it turns out seems like two viable options for the required capacity (i.e. you could host everything from either machine and you should have good performance). Nonetheless, I favor utilizing both resources among your users, since (1) they are available and (2) provide more scalebility for the future. I am making the following assumptions:

  • You only need a production environment (but you can have VMs to run the respective component on each machine for DEV, TEST, PROD)
  • Your 25-50 users don't need to see the changes instantly (i.e. daily update is sufficient)

Having said that, here is my recommendation:

Old Server: Database server

  • Upgraded to Windows Server 2012
  • PostgreSQL Database
  • File geodatabase with mosaic dataset to store raster data
  • Will host the master geodatabase for replication and serve the ArcGIS Desktop users (using direct connect)
  • This machine still provide faster disks and plenty of RAM to support database operations.

New Server: Web and GIS server

  • IIS
  • ArcGIS Web Adaptor (optional: see my blog post for a decision cheat sheet)
  • ArcGIS for Server Enterprise Standard or Advance (requires 2 license, but that doesn't seems like an issue)
  • Portal for ArcGIS (if required)
  • One file geodatabase replica from the database server to host the map services (it will provide better performance; only use enterprise geodatabase to support feature services)
  • A second file geodatabase with mosaic dataset to store raster data and support map services (robocopy from database server)
  • Will server your web map users, as well as development and learning web maps and map services

If it wasn't for the size of your vector data and expected growth, I would have switch the server around and recommend using ArcGIS for Server Workgroup, with MS SQL Server Express, instead (which is restricted to 4 cores license). This would have significantly reduce administrative overhead. This alternative might be feasible if you can breakdown your vector data logically (i.e. no relational or spatial dependencies between feature classes, such as topology or shared edge editing) into multiple enterprise geodatabase under 10GB.

A final note on public consumption. ArcGIS Online can be a viable option to host public content with the main advantage that you don't need to worries about capacity and peek usage. Please find this blog post regarding uploading feature services to ArcGIS.com.

  • In the interests of rounding out an already great answer, what might a "bad one" look like? – matt wilkie Jan 15 at 20:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.