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