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 we are talking about the SAS servers and services, users, and client products such as SAS Enterprise Guide, I believe that SAS connection profiles are worth mentioning.
Logging In
When users log on to a client, or an admin logs on an admin tool – whether it is a desktop or web client – a connection profile is used. Then, users or admins connect to the metadata server. In order for the web or desktop clients to “find” the metadata server, we need the metadata server “address,” aka connection profile. The connection profile simply stores user credentials, ports, and server names. You can find the profiles in the following location for SAS Data Integration Studio, SAS Information Map Studio, SAS Management Console and SAS OLAP Cube Studio:
Windows Vista or later: C:\Users\user-name\AppData\Roaming\SAS\MetadataServerProfiles
UNIX: /user-home/SASAppData/MetadataServerProfiles.
The client profiles have the extension swa. Here is a snippet of a client profile:
port=8561
userid=sasdemo
Name=SASDemo
password={sas002}1D57933958C580064BD3DCA81A33DFB2
host=machine_name
In this profile, the user name and password are stored, which means the user will not be prompted. The users have the option to check a box during login that saves the user ID and password in their profile.
| Tip: If you would like to avoid that users have the option to check this check box, you can do the following:On your metadata server machine, go to sas_config_dir\Lev1\SASMeta\MetadataServer and open the file omaconfig.xml.Change the value for SASEC_LOCAL_PW_SAVE from 1 to 0, where 1 is YES and 0 is NO.Save your changes and close the file.Restart your metadata server for the changes to take effect. Please keep in mind that the restart of the metadata server will throw out all your users, meaning, their work will be interrupted. For that reason, you might want to choose a time where there is the least user traffic.This will disable the check box to save user ID and password from the profile. |
Quick excursion to SAS encryption
Looking at the client’s .swa file, you might notice the password:
password={sas002}1D57933958C580064BD3DCA81A33DFB2.
SAS encrypts password at rest and in transit. There are several encryption mechanisms available in SAS. Here, you see sas002, which is the default SAS encryption called SASProprietary, which is a fixed coding algorithm with medium security.
OK, that was the SAS Application Servers. Next, I would like to take a moment and look at the SAS Object Spawner.
Object Spawner
Another important SAS component that we must talk about when talking about SAS application servers is the Object Spawner. An object spawner runs on each machine where you want to run a workspace server, pooled workspace server or stored process server.
The Object Spawner’s task is it to launch a workspace server, pooled workspace server or stored process server, whenever one is requested. If a user accesses a table in SAS Enterprise Guide to work with it, the workspace server is used to execute the user’s job, right? Not quite. The component that actually starts a workspace server session is the Object Spawner.
Before the Object Spawner starts any of these application servers, it establishes a communication with the metadata server to check whether the requesting user has a valid user ID.
To be able to have a communication between the Object Spawner and the metadata server, the object spawner uses a configuration file that includes the information needed to access the metadata server. The configuration file is called metadataConfig.xml and is located at SAS-config-dir\Lev1\ObjectSpawner.
It includes the metadata