objects using application server specific configuration files that are automatically created when SAS is installed. You can look at the SAS Application Server definitions in SAS Management Console, Server Manager. The SAS Application Server Context is called SASApp by default.
Most SAS Application Servers are structured with a Logical Server component and a Server component. Figure 2.5 is an example for the Stored Process Server.
Figure 2.5: Stored Process Server Structure
The SAS Application Servers are simply SAS processes, fulfilling all different types of user requests. The workspace server is used for general client user interactions. The stored process server is used for stored processes, and so on.
| Note: You must not rename the name SASApp. Configuration files use this name reference and its configuration settings for SAS client interactions. Renaming SASApp could result in your users not being able to run jobs within SAS clients. |
Underneath the SASApp, you can see the various dependent SAS Application Server objects, and the way they are structured. Almost all server components consist of a Logical Server component and a Server component.
Logical Servers and Servers
SAS servers, such as the workspace server or stored process server for example, can be grouped into logical objects. That means, you can have multiple servers grouped together under one logical application server.
Let’s stick with the SAS workspace server for a moment. An example for server definitions under a Logical Server definition is:
But it could also look like
As you can see in this example, a Logical Server can have one Workspace Server definition or multiple. In this case, I created two additional workspace servers based on the department I work in, called Customer Success. In this department, we have a group of Systems Engineers and Customer Success Managers. We separate the workspace servers for both groups for purposes such as:
You want a certain group of users to run their jobs in a specific application server. Every time a user (such as a Systems Engineer) runs a job, the job is executed by a specific workspace server (Systems Engineers Workspace Server).
You can also use it if you want to assign certain content. We could assign specific SAS libraries to each individual group, as in our case, libraries for Systems Engineers and libraries for Customer Success Managers.
Additional logical servers are created using the SAS Deployment Wizard.
Another example for a scenario in which the creation of additional servers might make sense is in a dev, test and prod environment.
Creating dev, test, prod environments (additional SAS 9.4 instances) is a big topic in itself, and the example for creating additional servers for a dev, test, prod environment is just one example. Another way to set up multiple SAS 9.4 instances is with the SAS Migration Utility. The Appendix of this chapter will provide you with the resource reference, talking about how to copy existing deployments to create additional SAS 9 instance using the SAS Migration Utility.
There are many great discussions about this topic on the SAS Administration and Deployment Community. One of which I would like to highlight is Running two SAS Environments on the same Linux machine.
The question was if there is a best practice for deploying SAS 9.4 on the same machine to create additional separate environments. In this case, the user was looking to create a second SAS 9.4 instance on the same machine. Paul Homes, an expert and owner of the SAS partner metacoda, provided some great information that I would like to share with you. The question was for Linux, but the concept can be applied to other operating systems flavors as well. I would like you to focus on the pros and cons described. Paul’s answer to the question:
You can definitely run 2 environments on the same machine (given the machine is suitably sized in terms of memory, CPU, storage, etc.). Use the SAS Deployment Manager to do an install and deployment of Lev1 and then run it again to do another deployment of Lev2. You can choose different Lev numbers as long as they are different for each environment on the same machine. By choosing a different Lev number all of the default port numbers will be automatically chosen to avoid conflict.
Of course, there is also the option to have multiple virtual machines on the same physical machine.
If you are not installing new ‘empty’ environments then the SAS Migration Utility can be used to create a package based on an existing SAS environment so you can use it during the deployment of a new environment. Alternatively, you can use the export/import tools to migrate metadata and content using SAS package files post-install.
A benefit of having both environments on the one machine is one less machine to procure and manage. A downside is that the machine will need to be bigger to support both environments. Being less isolated can also make it harder to do changes to one environment without potentially impacting the other environment. (...) Imagine a DEV and PROD on the same machine. You wouldn’t be able to test opsys and SAS patches on DEV prior to their application to PROD. You wouldn’t be able to reboot the DEV machine without rebooting the (same) PROD machine.
As to whether the pros outweight the cons or vice-versa depends on how you plan to use the environments. I would definitely recommend consulting SAS Professional Services or a local SAS Partner if you want some help with planning.
I went a bit of track there, let’s get back to our SAS Application Servers ...
SAS Application Servers are accessed either by desktop clients or, by web applications that run in the middle tier. Logical Servers are “holding” the Servers that you have per default, plus, any custom servers should you decide to add them. The workspace server is just an example. It is the same concept for other SAS Application Servers as well.
Logical Servers contain one – and one only – application server definition, such as the workspace server. The object name SASApp – Workspace Server or SASApp – Stored Process Server etc., hold the information for the server that executes SAS code. If you look at the properties for the SASApp – Workspace Server for example, you’ll see the following:
The file WorkspaceServer.bat includes the information needed to start the workspace server and the selected server machine is the machine where the server runs on. Customers create additional servers to separate group access, as one example.
The hardcopy readers amongst us are probably getting close to hit me with my admin book, because I would like – once more – highlight a paper that goes with the SAS workspace server and might come in handy should you ever experience any delays with the SAS workspace server initialization. But remember all these links can be found on my author page in a handy pdf. The paper is called: Tracking Down the Culprit of a SAS® Workspace Server Initialization Delay, available at https://www.sas.com/content/dam/SAS/support/en/sas-global-forum-proceedings/2018/2003-2018.pdf.
SAS Connection Profiles
While
