ArcGIS files on OS X Server

[Great_LandTrust]

Hi there,

We've recently moved some of our storage an OS X server. We access it via SMB1 on the Windows 7 machines that are using ArcGIS 10.

By and large, things seem to be working well, but one of our users has been experiencing hangs whenever geoprocessing tasks are run. The connection to the server seems to be lost, and it either requires a restart to reconnect or waiting for some significant period of time.

My question is twofold.

1) Does anyone have any experience with different server environments causing trouble? IE, is ArcGIS only happy running on Windows Server and nothing else?

2) Has anyone else experienced anything like this ever?

[VinceAngelo]

It's against best practice to expose file geodatabases by networking protocols.  I did some benchmarking that indicated that it didn't really matter which networking protocol was used -- File geodatabase was always significantly slower over a network.  I thought this wouldn't hold true for Linux over NFS, but it did (and on some systems with an older OS, it was very significant -- the worst of all test cases).  It's not a Windows Server happiness issue, because the FGDB API was quite performant on Linux with a local disk. When it comes to file geodatabase, the rule is "local disk is best."

- V

[Great_LandTrust]

Thanks for your reply - it's immensely appreciated! Currently, is it possible to store a geodatabase locally and the reference files on the network share? Or is that also not recommended?

[VinceAngelo]

The meaning of "reference files" is unclear.  I only tested feature class creation, feature population,

index construction, spatial and non-spatial indexed queries, and feature class deletion.  If you're

referring to a mosaic dataset, I'd imagine that networked performance would be degraded but

you'd have to test performance to verify that yourself.

- V

[JoshuaBixby]

There is something straightforward and likeable about "local disk is best," but the situation isn't quite as simple when we move into the realm of best practices and enterprise GIS.  Although I have experienced firsthand the performance and stability challenges of exposing file geodatabases over networking protocols, I am trying to recall whether I have seen it documented as being against best practice.  Is there a good, singular source for file geodatabase best practices or is it a best practice here and another one over there?  The GIS System Design Strategies Wiki has best practices scattered throughout it, but it wasn't until the 34th edition in the spring of 2014 that file geodatabases were included in certain sections of the Network Communications chapter.

The struggle with implementing a local-disk-is-best policy in the enterprise is defining what exactly local means.  I don’t think anyone could argue that SAS and SATA aren’t local, but does local apply to Thunderbolt, eSATA, USB, Firewire?  If so, what about USB 2.0 versus 3.0?  What determines calling something network storage?  The presense of TCP/IP or maybe Ethernet?  Is iSCSI over gigabit Ethernet considered network and bad?  What about iSCSI over 10 gigabit?  Of course there are the different versions of SMB as well.

I think there is value in working with best practices, but practices need to be defined in a meaningful way so they can be used by a wide range of users, including the enterprise.

[VinceAngelo]

I think my terminology is adequate to the task.  If you want to use an exotic networked solution that is indistinguishable from local disk characteristics under all use cases and loads, then that would be considered "local" (fibrechannel attached devices are usually in this category, unless the drivers are poor).  If you use a USB 1.0 device that behaves like a SATCOM link, it's not local.  It's easy enough to benchmark performance with real data against various disk solutions to determine what makes the grade.

[Great_LandTrust · Accepted solution]

As a follow up to this - while a local disk only policy was discussed, it's definitely not the optimal way to share work between multiple people who might need to work on the same dataset. Upgrading OS X Server to version 4.0 (OS X 10.10 is required), which features a significant re-write to the smb sharing protocol, seems to have made the instability go away. Users are still reporting ArcGIS quitting unexpectedly, but I believe that has more to do with a recent hardware/OS upgrade than any specific network issue. We'll see.

The upshot for me, though, is that smb version matters. If I was stuck with using smb in OS X Server I'd recommend version 10.6, 10.10, or using a solution that implements the traditional smb stack, such as SMBup.