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.
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:
-
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.
-
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.
-
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:
-
Expand the SASApp application
server, right-click Logical Workspace Server, and then select
Add Server from the pop-up menu. The New Server Wizard
appears.
-
Specify the name for
the new server that is being added to the client-side pool and click
Next.
-
Click
New. In the
Add New Machine dialog box, enter
the name of the new machine where the server resides, and click
OK.
-
In the Available list,
select the new machine.
-
Click
Advanced
Options, and then select the
Performance tab.
-
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 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:
-
Right-click the Server
Manager and select
New Server from the pop-up
menu. The New Server Wizard appears.
-
In the wizard, choose
Object Spawner as the type of server, and then click
Next.
-
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.
-
Start the metadata server.
-
Start the object spawner
on the machine that is being added to the pool.
-
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.
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.