There are three main components in ArcGIS for Server, a Web Server which receives requests and forwards them, and a GIS Server which processes and executes the requests. And the configuration store which holds details of the Server Site. The three components can be arranged into different architectures. Following are some illustrated architectures:
It's every man for himself.
This architecture explains the different components of ArcGIS for Server, the GIS Server, the main part which does the processing, the Web Server which is an optional part that receives requests and forwards them to the GIS Server, the geodatabase server which holds your data and last server which holds the Server Site configuration.
The client sends a request to consume a GIS service to the Web Server on port 80 (by default, this can be changed of course) the web server forwards it to the Server Site to a GIS Server, the GIS Server will need to fetch some details from the configuration store about the Server Site, the GIS Server processes the request, it might need to connect to the geodatabase to fetch some data.
This model, It's every man for himself, shows how to distribute servers so everyone can perform one task.
Better management as each node can be monitored separately.
Expensive, needs a lot of servers + Heavy networking communication.
I can do that
This model is similar to the previous one, the different is that we got rid of the Storage server for the site configuration and placed it with the Geodatabase Server. The geodatabase server can do the job of the storage server.
Saves one server and higher availability as configuration data is located with the geodatabase.
- If the Geodatabase failed the entire Server Site will collapse since the configuration store will no longer be available
Cut the middle man
This model removes the Web Server from the picture thus establishes direct connection with the GIS Server over port 6080
Less networking traffic and configuration
-Port 6080 should be opened by the firewall, thus introducing security vulnerabilities.
-No control over who can access the server, which was the job of the web server.
Keep her out of this
This model isolates the geodatabase from the Server Site, the GIS Server will take care of the Config Store. Still the Web Server can control the traffic.
-No Server is required for the Config Store
-If the GIS Server fails the Server Site is no longer accessible.
-Heavy networking activity
Keep them out this
This model is similar to the previous one, except that the Web Server is removed, thus less configuration and servers.
The Three Musketeers
This model is setup so that no networking is required at all, the geodatabase, config store are located in the GIS Server. This model is good if the geodatabase is read only. The admin can duplicate multiple GIS Servers with Network Load Balancing between them. In case one fails another can take over.
Redundancy, if a server failed another takes over and have all what it needs
No Networking Traffic, fast retrieval of data. (Data Locality)
Redundancy again, since if the geodatabase changed you have to update all GIS Servers.
This model is interesting, it is similar to the Three Musketeers , except that the Web Server joins the troop. This model adds the benefit of the Web Server configuration and permissions.
We will introduce another topic where we explain multiple GIS Servers in the server site.