Configuring Client-side Pooling

Configure Client-side Pooling across Multiple Machines

If your deployment requires more than one host for client-side pooled workspace servers, then you can configure client-side pooling across multiple machines.

An important aspect of multi-machine workspace client-side pooling involves the puddle login ID that you supplied in the topic Convert a Logical Workspace Server to Client-side Pooling. In order to implement multi-machine, client-side pooling, this login must be valid for all machines in the cluster.

This topic describes a basic configuration where the client-side pool has only one puddle. For this basic implementation, the account that you use for the login ID must be able to authenticate on every machine in the cluster. This means that the login ID must be a network account, and it must be associated with a single authentication domain in metadata (for example, NTDomain).

If you require a workspace client-side pool that consists of host servers in different authentication domains (for example, Windows and UNIX), then you can configure a pool with a separate puddle for each host. Each puddle has its own login ID as appropriate for the host's authentication domain (for example, NTDomain or UnixAuth). Each login ID must be able to authenticate on every machine in its respective cluster. With this configuration, the pool manager software can identify which machine is used for a given process, based on the puddles that are defined for the pool, and it uses the appropriate login to make a connection.

The following instructions explain how to configure workspace client-side pooling across two machines in the same authentication domain, both supporting the same puddle. Repeat these instructions as appropriate for each additional machine that you want to configure for that same puddle.

Note: These instructions assume that you have already set up and verified client-side pooling on a single machine, as explained in the previous sections. [cautionend]

To configure client-side pooling across two machines, follow these steps:

Log on to SAS Management Console as the SAS Administrator (sasadm@saspw).
If the puddle login ID is not accessible to all machines in the client-side pooling cluster, then you must create a new user. Follow these steps:
1. On the host, identify or create a network account. For example, on Windows the user name might be NTDomain\myaccount. The user must authenticate against each machine in this cluster.
  
  If creating the account on Windows, grant the "Log on as a batch job" user right for the account on each Windows machine in the cluster.
2. In the SAS Metadata Console User Manager plug-in, add a login to the SAS General Servers group with the user ID and password of the user that you just created.
  
  This login should be associated with the server's authentication domain (for example, DefaultAuth or ServerAuth), even if you are using middle-tier trusted authentication. The login is used to start processes on the server machine rather than to authenticate against the metadata server.
3. Change the login ID that is used for the puddle to this newly established login ID. Make this change in the Edit puddle dialog box, which is accessed from the Logical Workspace Server Properties dialog box under the Server Manager plug-in. For details, see Convert a Logical Workspace Server to Client-side Pooling.
In the SAS Metadata Console Server Manager plug-in, add a pooled workspace server definition for the machine that you are adding to the client-side pool. Follow these steps:
1. Expand the SASApp application server, then right-click Logical Workspace Server and select Add Server from the pop-up menu. The New Server Wizard appears.
2. Specify the name for the new server that is being added to the client-side pool and click Next.
3. Click New. In the Add New Machine dialog box, enter the name of the new machine where the server resides, and click OK.
4. In the Available list, select the new machine.
5. Click Advanced Options, and then select the Performance tab.
6. On the Performance tab, set the client-side pooling options for this machine and then click OK. The maximum number of clients can vary for each server that is included in the pool, and should be configured based on the capacity of each physical server that is being used. For details, see Configure Client-side Pooling Properties for Each Server.
Click Next.
Click Next to accept the default authentication domain and port.
Review the information in the summary dialog box. If no changes are required, click Finish.
To define a new object spawner, in the Server Manager plug-in, follow these steps:
1. Right-click the Server Manager and select New Server from the pop-up menu. The New Server Wizard appears.
2. In the wizard, choose Object Spawner as the type of server, and then click Next.
3. Provide information in the wizard as appropriate, by using these guidelines:
  - Select the host name that you are adding to the pool.
  - Select the newly created pooled workspace server as the server to be spawned by this object spawner.
  - Accept defaults for operator connection, ports, and authentication, unless you have implemented these differently.
Under SASApp, expand the logical pooled workspace server, and verify that both physical workspace servers appear under the logical client-side pooled workspace server.
Install the necessary SAS software on the machine that is being added to the pool. At a minimum, you should install Base SAS, the SAS Workspace Server, and the SAS Object Spawner. When configuring the object spawner, make sure that the object spawner can connect to the metadata server (running on another machine). If the spawner cannot access the metadata server, then the object spawner cannot be started.
Verify that pooling works for SAS Web Report Studio.
1. Start the metadata server.
2. Start the object spawner on the machine that is being added to the pool.
3. Start or restart the middle-tier components.
  
  Note: Because the client-side pool administrator did not change, there is no need to change the middle-tier configuration. Recall that the pool administrator (typically sastrust@saspw) is used by the middle-tier application to process client-side pooling requests.
Depending on the puddle configuration and the maximum number of clients that are allowed for each server under the logical client-side pooled workspace server, the number of pooled workspace server processes that show up on each machine will vary.

For more information, see Verify That Client-side Connection Pooling Is Working for SAS Web Report Studio.

As mentioned earlier in this section, if you require a workspace client-side pool that consists of host servers in different authentication domains, then you can add more puddles to the pool. For each puddle, provide a login ID that is able to authenticate against all machines in the cluster.

The data sets that are accessed by the client-side pooled workspace server processes must either be replicated on each machine that will execute the pooled workspace server processes or accessed via a shared location that uses a common shared path--for example, a UNC or NFS path. For more information about putting the data in a shared location, see Overview of Managing Data and Catalogs for Servers on Multiple Machines. Alternatively, the workspace server processes can access data by using some other sharing mechanism, such as a SAS/CONNECT server. All LIBNAME assignments use the same path information, regardless of which physical machine the process runs on.

The object spawner process on the machine that has been added to the client-side pool cannot be started until the metadata server is running. If the object spawner is configured to run as a service that starts automatically, then this dependency cannot be enforced via the Windows services configuration.

Top of Page