A cluster of ATG servers must always contain the following:
exactly one process editor server
zero or more global scenario servers
zero or more individual scenario servers
Each individual server handles all the individual, or visitor-specific, events (such as “Visits Page”) for the profiles whose sessions are on that server. For example, suppose you have a simple scenario that records all the page visit events to a dataset. When someone visits a page, the corresponding individual server receives the page visit event and performs the scenario action that records the data.
Global scenario servers, in addition to handling the individual events for any of their own sessions, handle global events (such as “Dynamo Starts”), and timer events (such as “Wait 3 hours”). In general, they handle any operations that are not visitor-specific. For example, if you have a scenario that sends e-mail to all your visitors, the scenario action to send the e-mail is executed on a global server.
The process editor server is a specific instance of a global server. In addition to handling global events and the individual events for any of its own sessions, it is also responsible for starting and stopping scenarios. You can create and edit scenarios only in the ACC that is connected to the process editor server.
Important Note About Creating and Viewing Scenarios in the ACC
As stated above, you can create and edit scenarios only in the ACC that is connected to the process editor server. However, your scenarios are not automatically visible in an ACC connected to another server (individual or global). To make them visible, make sure that your standard deployment procedure for scenarios copies your entire configuration (including all scenario XML files) across all scenario servers in your system. If you follow this procedure, scenarios created on the process editor server do appear with read-only access in an ACC connected to another server.
Using the Same Instance of ATG 9.3 for More than One Cluster of Servers
You can use the same instance of ATG 9.3 for a single cluster of scenario servers, but do not use the same instance for more than one cluster. In other words, you can have a cluster of scenario servers running on one or more machines that all use the same installation of ATG 9.3, but additional clusters, including those that you use for production or staging, should be set up to run on separate installations of ATG 9.3. This configuration is required because any changes you make to a scenario on a server in one cluster are written to the top-level localconfig directory for that installation. Those changes are propagated to all other servers using that installation, including servers in other clusters. This behavior is desirable among servers in a single cluster, but it is undesirable in other situations—for example, between servers in your development and production environments. This caveat also applies to servers that you use to run workflows.
