Register Data Folders for Multi Machine ArcGIS Server Site

1376
6
Jump to solution
03-15-2017 08:12 AM
GarethBaker1
Occasional Contributor III

I'm trying to follow the guidance in these documents regarding registering data in a folder for a multi machine site

http://server.arcgis.com/en/server/latest/administer/windows/data-storage-considerations-for-an-arcg...

http://server.arcgis.com/en/server/latest/publish-services/windows/overview-register-data-with-arcgi...

I understand the concept of placing an identical copy of the data on every server machine but it's not clear how you are then supposed to register that data with the site.

For example if I place a file geodatabase in D:\GISdata on machines A and B then how should I be registering these with the site? Ideally I want to be able to publish to the site from my local desktop PC a map service which references the data on one of the servers e.g. \\serverA\gisdata but then if it happens to be server B fulfilling a particular request it should go to its own local copy of the data, not the one on server A.

I thought maybe that I could register \\serverA\gisdata as the Publisher path and then D:\GISdata as the Server path in the register data source dialog but it throws an error saying that it can't access that location. If I use the UNC path for both Publisher and Server paths it validates successfully so it's not a permissions issue and I have checked that the domain account running Server has read/write access.

Am I missing something obvious here? If I just go ahead and register the server A path via UNC will the site automatically resolve this to server B when B handles a request or am I creating extra traffic and effectively making the copy of the data on B redundant?

Tags (1)
0 Kudos
1 Solution

Accepted Solutions
JonathanQuinn
Esri Notable Contributor

You're right, for performance considerations, local data will always be faster than UNC data.  Ideally, you'd be able to compare the performance of data served locally and data served through a UNC and see if the difference is enough to warrant the additional overhead of maintaining two copies.  Of course, that requires you to actually be able to register the data location in both ways, so we'll need to figure out why you can't register the data location when using the D:\ drive.  Something you can try is to run ProcMon, run a filter to only return file system operations against the data store you want to register, and try to register it.  That should show you the request Server is attempting to make to the folder location, and give you an indication of why it fails.

View solution in original post

6 Replies
JonathanQuinn
Esri Notable Contributor

You should place the data in one location, share the folder so you can access it via a UNC path, and then publish the data from that location.  The Publisher Connection and the Server Connection will be the same in that case, and you won't have to worry about making sure the data is redundant and synchronized.  The accounts running the ArcGIS Server Windows service on each ArcGIS Server machine should be able to reach the data through the share.

GarethBaker1
Occasional Contributor III

Hi Jonathan,

That would seem to be the opposite of the advice given in the online help.

http://server.arcgis.com/en/server/latest/administer/windows/data-storage-considerations-for-an-arcg...

When you use a file geodatabase as a data source, you should place an identical copy of the file geodatabase on each GIS server machine. For example, in an ArcGIS Server site with three GIS servers, each GIS server should access its own copy of the file geodatabase. The GIS servers should not access the same file geodatabase over the network.

I can see why it would be a lot easier to have a single copy that all server machines access but it's not a route we want to go down if the performance is going to suffer.

Regards

Gareth

JonathanQuinn
Esri Notable Contributor

You're right, for performance considerations, local data will always be faster than UNC data.  Ideally, you'd be able to compare the performance of data served locally and data served through a UNC and see if the difference is enough to warrant the additional overhead of maintaining two copies.  Of course, that requires you to actually be able to register the data location in both ways, so we'll need to figure out why you can't register the data location when using the D:\ drive.  Something you can try is to run ProcMon, run a filter to only return file system operations against the data store you want to register, and try to register it.  That should show you the request Server is attempting to make to the folder location, and give you an indication of why it fails.

GarethBaker1
Occasional Contributor III

Hi Jonathan. Thanks for this. I have managed to track down what the issue was. I hadn't completely set the permissions correctly on server B so I assume that when you try to register the data source it scans all machines in the site to make sure it can access that location.  This explains why it worked if I put the UNC for server A in because that had the permissions set correctly.

I think it would be useful to add something in to the guidance to say that if you're putting data on each machine to make sure that you use the local reference in the path and that all machines need to be set up correctly first.

Regards

Gareth

0 Kudos
GarethBaker1
Occasional Contributor III

Just one quick follow up. I assume it's necessary to register the UNC path for both server A and B with the site and in both cases make sure that the server path is set as the local D drive? That way it shouldn't matter if a publisher decides to put the data from either A or B into their mxd as the server will replace both references at the point of publishing.  The alternative would be to make sure that a publisher only ever uses data from one server in their mxd?

0 Kudos
RebeccaStrauch__GISP
MVP Emeritus

I would agree with that.   We don't have multiple machines in one deployment, but do have our developer machine and production.  That is how we handle moving our MXD/data and publishing our developed/tested services to production.  That is, "in both cases make sure that the server path is set as the local D drive".  We do copy our data local on each machine in most cases.

0 Kudos