Guidelines for configuring ArcGIS Server components |
|
Release 9.3 |
![]() ![]() ![]() |
An ArcGIS Server system is composed of many parts, such as the server object manager (SOM) and server object container (SOC); the Web and Mobile Application Developer Frameworks (ADFs); a Web server; and an administration interface, such as Manager. For the system to work, each component must be able to communicate with the other components in the correct way. You'll also want to wisely distribute the components so as to make most efficient use of your hardware. This topic provides information on how the ArcGIS Server system components interact with each other and the relative amount of resources they consume. You'll also find options for high-availability configurations so that a hardware failure does not disable your applications.
When reviewing this information, be aware that ArcGIS Server Workgroup licensing allows for the deployment of ArcGIS Server components on just one machine. To deploy ArcGIS Server components on multiple machines, you must have the Enterprise level license.
The SOM is a component of ArcGIS Server that manages the services distributed across one or more SOC machines. The SOM runs as a background process (in Windows, it's the ArcSOM.exe service. On Linux/Solaris, it's arcsom.exe) and handles the load distribution of incoming requests. It also keeps track of which services are running on which SOCs. Using this information, the SOM delivers a request to the appropriate service.
The ArcSOM.exe process uses relatively little memory and does not need to run on a dedicated machine; it can coexist with the Web server or reside on a SOC machine. For information on installing the SOM, consult the ArcGIS Server Install Guide by opening install.htm on your installation CDs, or by navigating to the <ArcGIS install directory>/Documentation/install_guides folder on your computer.
In deployments with multiple Web servers and SOC machines, the SOM can be a single point of failure, meaning that if there is only one SOM, it could stop the whole system by going offline. For this reason, you may want to set up multiple SOMs for use in a failover or round-robin configuration. In a failover configuration, all requests for services are sent to one SOM. If that SOM fails, a designated backup SOM continues fielding the requests. In a round-robin configuration, by contrast, requests are distributed evenly among all available SOMs in the configuration. If a SOM in a round-robin configuration goes offline, the remaining servers continue fielding requests.
ArcGIS Server allows failover or round-robin configurations when you add services to a Web application, either at design time or programmatically.
When you run the GIS Server Post Install, you are prompted to enter a name and password for the SOM Account. This account runs the Server Object Manager service. The server account is automatically granted permissions to the default log directory so that it can write the log messages. If you ever change the log directory, you need to make sure that the SOM machine can access the directory, usually via a UNC path, and that the server account is granted permissions for the new directory.
The agsadmin and agsusers user groups specify the privileges that a user will have when making a local connection to the GIS server. These groups are automatically created on the SOM machine when you install ArcGIS Server, but it is your responsibility to populate them. You should add yourself to the agsadmin group, as well as anyone else who will need to administer the server. Then you can add anyone else who will use the GIS server into the agsusers group.
SOC machines host services and the processes that do things with those services. In this way, the SOC is the work center of the GIS server. SOC processes are started and stopped by the SOM.
All SOC machines associated with a SOM must have the same edition (Basic, Standard, or Advanced) of ArcGIS Server installed. For example, if a SOM has three SOC machines associated with it, all three of those SOCs must have the same edition of ArcGIS Server.
Adding or enhancing SOC machines is the most direct way to boost the performance of your ArcGIS Server system. You can add SOC machines or additional CPUs to SOC machines already on the system. It's important to note that the SOM assumes that all SOC machines have the same configuration (speed of CPUs and amount of RAM) when it balances the load across the system. The SOM also assumes the same licensing exists across all SOCs, meaning if your system makes use of functionality provided by one of the ArcGIS Server extensions, then it's assumed that all SOC machines are licensed for that functionality.
Note that you must have the Enterprise level of ArcGIS Server to install ArcGIS Server components on more than one machine.
Occasionally you may need to remove a SOC machine. When you remove a SOC machine from your system, the GIS server will more heavily utilize the resources of the remaining SOC machines in your system, which may affect performance of the GIS server as a whole. The services that had been running on the machine you remove will be reallocated to other machines.
On Windows, when you run the GIS Server Post Install, you are prompted to enter a name and password for the SOC Account. When the server object manager starts a container process, the container process runs as this account. Since you do not know the SOC machine on which any given process will be started, it's important that you specify the same name and password for the SOC account for each machine on which you run the GIS Server Post Install.
On Linux/Solaris, the install owner, SOM account, and SOC account are the same user account. If you install different components on different machines (distributed setup), it is strongly recommended that you use the same username/UID/password on all the machines. If, however, it is not possible, all install users on all the SOM and SOC machines must be added to the ArcGIS Server Users list on every SOM machine.
On Windows, the GIS Server Post Install gives you the choice of specifying an existing account or letting the software create the account for you. If you choose to let the postinstall create the SOC account for you, it is only granted privileges to launch container processes and write to the system temp directory. This means that you have to manually grant permissions for the SOC account to access any data and directories used by your services. Failure to grant adequate permissions to the SOC account is a common cause of services not displaying as expected.
On Linux/Solaris, the setup gives you a choice of specifying an existing account, or letting the install create the account for you. For a complete install - the SOM and SOC are on one machine, the install already granted permission to this account to access <ArcGIS server Installation directory>/logs/server/SOM_logs folder and "arcgisoutput", "arcgiscache" and "arcgisjobs" directories under <ArcGIS Server Installation Directory>/server/serverdir folder. For distributed setup , if you install ArcGIS Server as the same username/UID/password, this install account should be able to access those directories as well. Otherwise, it is important to grant such users on the SOC machine permission to read the SOM log folder and permission to write to the "arcgisoutput", "arcgiscache" and "arcgisjobs" directories on each of the SOM machines.
The SOC account must have at least read access to any GIS resources (maps, locators, data) that your services require to do their work. This includes all the data referenced in the resource. For example, to publish a map document as a service, the map document and all the data for its layers must be in locations to which the SOC account has permissions. To ensure that all SOC machines reference the data in the same way, you can either use UNC paths or store a local copy of the data at an identical path on each SOC machine. The latter option is impractical for large or frequently changing datasets.
If a service makes use of a server output directory, ensure that the container account has read/write permissions to the directory. If your application will query the server log files using the Server API, make sure the container account has permissions to the log directory.
When adding a SOC machine to your server, be sure to type the exact name of the machine; do not use localhost.
The Web server hosts the Web services and applications that you create with the ADF. It receives requests from clients and relays appropriate tasks to the GIS server. Because there are different "flavors" of Web servers, you should consult your own Web server's documentation for specific details on its setup and troubleshooting.
For optimum performance, it's recommended that you deploy the Web applications and the REST and Web Services Handlers to a production quality Web server. The Web servers used internally by ArcGIS Server are not intended to be used in a production environment. Please refer to the System Requirements for a full list of supported servers. Among the popular ones are IBM WebSphere, BEA Weblogic, and so on.
It's also recommended that you configure an appropriate heap size for your web server's JVM using the -Xms and -Xmx JVM flags. This will greatly enhance the scalibility of your Web applications. For example, starting with an initial heap size of 256MB and going up to a maximum of 1GB by using the JVM options "-Xms256m -Xmx1024m" is usually sufficient. Please check your Web server's documentation for details on how to configure the heap size.
Each Web server in your configuration must have the ADF Runtime installed and must have access to the Web application or Web service that you want to run. The SOM and SOC components of the GIS server can also reside on the same machine as the Web server. This is especially useful in small developer configurations or where hardware is limited.
Your ArcGIS Server system can include more than one Web server. Reasons for using multiple Web servers include increased computing power for handling traffic to your site and the ability to keep your site online in case one of the Web servers goes down. Network load balancing techniques can help you distribute requests evenly between the Web servers. Some sites that require constant availability maintain Web servers in more than one geographic location so that a natural disaster or power failure does not take all their Web servers offline.
The diagram below displays - for the Windows platform - which postinstalls, accounts, and permissions are required for each machine in your ArcGIS Server configuration. Each machine in the diagram contains some green text denoting which postinstall you must run on that machine. Items in blue are accomplished by the postinstall. Items in red are things that you must do. Note especially that you must manually add the ArcGIS Web services account on each dedicated SOC machine.
If you're installing ArcGIS Server across multiple machines, the SOM, SOC, and ArcGIS Web Services accounts must use the same names and passwords on each machine. For example, if you run the postinstall on a machine and you accept the default name of ArcGISSOC for the SOC account, you must use the name ArcGISSOC for the SOC account on any other machine on which you run the postinstall. The passwords must similarly match.
The diagram below displays the user list for the Linux/Solaris platform. This is the list for a machine installing the SOM component. For a SOC machine, there's only superuser and the install owner needed at the OS level.
ESRI maintains a System Design Strategies white paper that contains recommendations for system configuration and sizing. This document contains sections relevant to ArcGIS Server as well as other ESRI products.