Configuration Store Questions

[MarkLittell]

I am sure this has been done before. So I don’t have to reinvent the wheel, what is the best solution?

Scenario:

I have two Virtual Servers (ESXi) in the same AGS Site located in two different geographical locations. The other location is my disaster recovery site.

What is the best way to host the Configuration Store network location? Two clustered Windows Servers is overkill. Will RoboCopy every minute be sufficient?

How often are is the Configuration Store updated? Only when a service is published or changed?

Are there locks on files that I need to worry about?

Do the Directory Files (Cache, Jobs, Output, & System) need to be stored remotely too or can I place them on their respective C drive?

Thanks

- Mark

[JonathanQuinn]

If I understand your approach correctly, I think you'll find that type of setup has terrible performance. Any latency in accessing the config-store or directories may cause significant performance issues for Server, especially with the config-store.

I suggest you look into something described here. You'll have duplicated environments in each data center to minimize single points of failure.

[MarkLittell]

My proposed configuration is having the two servers in the same AGS Site but in two different geographical locations.

I currently have single machines in separate AGS Sites in the two geographical locations as you suggested. Problem with that setup is because all my services are secure and when switching between the two servers the user is prompted for the service username and password when the layer refreshes.

Note: I recently discovered I can use the same token key at both locations (that may help this situation) but I am not sure how well that will work, nor does it create a true redundancy of services.

Do you know the answers to the following:

How often is the Configuration Store accessed?

When does the Configuration Store change?

Can I place the Directory Files (Cache, Jobs, Output, & System) on the respective system's local drive and not on a shared network drive?

What solution did people use for the Configuration Store across geographical locations?

Thanks for your time and input.

[JonathanQuinn]

It should work as described in the link in my post:

Single-machine high-availability (active-passive) deployment—ArcGIS Server (Windows) Installation Gu... 

About ArcGIS tokens—ArcGIS Server Administration (Windows) | ArcGIS Enterprise 

Editing token settings in Manager—ArcGIS Server Administration (Windows) | ArcGIS Enterprise 

Looks like you may have already read through those pages though.

The configuration store is accessed quite often. It records information on new services, statistics on old services, any administrative changes and the status of internal operations and components. It'll change in the same situations.

You can, as long as they're separate, unique sites, (active/active or active/passive). That's the only supported configuration of multiple server machines that aren't in the same site. You'll also need to consider sticky sessions. For example, if a GP service is running on Server A, it'll only be running on Server A and the output will only be on Server A. Any request for the status of the job has to go to Server A, so sticky sessions will control that. Keep in mind federation is not possible with this configuration.

The solution that people use is separate environments in separate data centers, and you have processes in place to replicate data and content to the standby data center. Servers in each data center wouldn't rely on any data or resources from the other data center so you minimize single points of failure.

[MarkLittell]

If someone comes across this post, this is what I ended up doing. I am not saying this is the best solution. My setup is running, and we are not seeing any issues, yet.

Two 2016 servers in two geographical locations. DFS-Replication and Share are running. Because DFS requires the servers to be a member of a Domain, each ArcGIS server is a Domain Controller (for Domain redundancy) in the same domain, a simple 3 server domain.

The AGS Config-Store and Directories point to C:\gisdfs\ not a domain share and are their own DFS Replication.

I have another DFS Replication, c:\gisdata, that houses my Geocoder and File Geodatabase files. This has a DFS Share. I have services that point back to the Share and have it registered to the AGS server.

The third server in this domain is running Arc Desktop to publish the services. I had to join it to the domain because non domain systems cannot access a DFS Share.