Skip To Content

Upgrade a multiple-cluster site


This topic describes functionality that has been deprecated.

Prior to 10.7, ArcGIS Server administrators could configure server clusters within an ArcGIS Server site. Clusters isolated the services assigned to them from other clusters in the site. The ability to configure multiple clusters for your site was removed at 10.7.

Before you upgrade to 10.9.1, you should know whether your existing site has one cluster (which is likely if the site is at 10.4 or later) or multiple clusters. If your ArcGIS Server site has a single cluster (called default), no additional action is required. Your site's machines will continue to run all services.

If you are upgrading an ArcGIS Server site with multiple clusters to 10.9.1, the upgrade process automatically makes some significant changes to your site and also requires some action on your part.

About multiple-cluster sites

ArcGIS Server 10.1 introduced server clusters alongside server sites. Clusters were subelements of a single site, with each cluster being specialized—to host services of a particular service type, for example, or to handle a certain size of request.

An organization may have had one cluster to handle image services, another for geoprocessing services, and so on—all within a single ArcGIS Server site accessed via a single ArcGIS Web Adaptor.

Because of performance issues with multiple-cluster sites, it has been recommended to use ArcGIS Server in single-cluster mode since 10.4.

In an ArcGIS Server site without multiple clusters, any machine in the site can take any request. There is no load balancing between ArcGIS Server machines; instead, load balancing is handled by the Web Adaptor or third-party load balancer configured with the ArcGIS Server site. Services are managed by an optimized internal application server, which was introduced at 10.6 to improve performance of publishing and administrative operations.

Upgrade behavior for multiple-cluster sites

Whether your site has one or multiple clusters, you can upgrade your site using either the setup program or the command line utility.

During the upgrade process, the ArcGIS Server upgrade tool checks whether the existing site has multiple clusters. If it does, the tool stops all user-published services. It then moves all machines and services into a single cluster called default. If a default cluster already exists, the upgrade tool uses it; if not, the tool creates a new default cluster.

When the upgrade is complete, the site no longer has multiple clusters, and each machine in the site runs all services. This may be a significant strain on your machines' memory and processing capacities, which is why all user-published services were automatically stopped before upgrading. This gives you the opportunity to review your published services and choose to keep them in the site or remove them—either permanently or to be republished to a separate ArcGIS Server site. All services that had been stopped will remain so until you manually restart or remove them.

Alternatives to cluster architecture

As an administrator of ArcGIS Server 10.9.1, you still have options to isolate your sites by type or size, as clusters previously did.

For one, you could set up multiple ArcGIS Server sites. This option is particularly useful if you will have a large number of services, with most or all receiving regular use, as this increases the number of ArcSOC.exe instances that each machine in the site needs to run.

In another case, you might have services that receive very different levels of traffic; for instance, one service will constantly be handling several simultaneous requests, while others receive requests infrequently. Here, use the shared instance pool introduced at 10.7 to conserve memory usage for those infrequent requests while giving each high-traffic service its own dedicated pool of instances isolated from the shared pool. The shared instance pool enables you to have many low-traffic services running on your site without impeding site performance or increasing operational costs.

Learn more about shared instances

When you are confident that your site architecture will provide optimal performance to users without placing too much load on your hardware resources, restart the user-published services that had previously been stopped.