Understanding Server Pooling |
The following figure shows a connection to a pooled workspace server:
The Connection Process for a Client-side Pooled Server
Consider an example of a client-side pool configuration that consists of:
two puddles: Puddle1 and Puddle2
two groups: Puddle1Access and Puddle2Access
two SAS server machines with an object spawner on each
A user, User B, accesses a SAS client application, and the client requests a connection to SAS for the user. | |
The client application uses a special account called the pool administrator to connect to the SAS Metadata Server and to read the pool metadata. The pool administrator must be able to view the metadata for all the logins (puddle logins) that are used to make connections for the pool. The pool administrator also needs to be able to view the membership of the puddle access groups. The SAS Trusted User is the default pool administrator. Note: The pool administrator does not need to be able to view the login definition for the requesting user ID. | |
For each puddle, if the minimum number of servers and minimum available servers are not met, the client application uses the appropriate puddle login credentials to launch new server processes. The pool determines which puddle the requesting user ID can access. The pool selects a puddle where one of the following is true:
| |
The pool manager returns a server connection from the selected puddle as follows:
The user accesses resources and services on the SAS server. Authorization for content on the SAS server is performed by using the puddle login. When the user has finished using the server connection, the server process is returned to the pool, and it can be reused by other users. |
Copyright © 2010 by SAS Institute Inc., Cary, NC, USA. All rights reserved.