move, delete, or modify data sets in the MetadataRepositories and rposmgr directories.
You can remove metadata objects via SAS Management Console or by using metadata programming features using the SAS® 9.4 Open Metadata Interface. Before you delete or remove any metadata objects, I recommend the following information from the sasCommunity.org Planet: “Where is my stuff? Documenting what is stored in SAS Metadata” available at: http://www.sascommunity.org/planet/blog/category/metadata/. Note: if you are using the printed book version, I realize that having to type a link into a web browser is a bit laborious, but this is one of the articles that are really helpful, and hard to find if you don’t dig deep. Typing it is worth it.
Metadata server and system access
You can use the metadata server’s authorization model to control access to your SAS assets (aka metadata objects). SAS security does not include protection of configuration files or any non-SAS-related content. In the Appendix of the book, you will find an overview of the operating system protections for Windows and Unix/Linux. Chapter 6, SAS 9.4 Metadata Security will cover metadata server authorization.
How about a clustered metadata server? Let’s talk high availability!
You have the option to set up the SAS Metadata Server as a clustered configuration. A metadata server cluster provides redundancy and high availability, which helps you make sure your environment will continue to operate should one metadata server go down.
You can implement metadata server clustering at any time. It does not have to be set up during the initial install.
A common question is if the SAS clients know when one cluster node goes down and another one picks up. There is no configuration for your SAS clients necessary. SAS clients, such as SAS Management Console, keep a list of the metadata server cluster nodes, which is updated each time a client connects to the cluster.
Where changes are required is for the SAS Application Server tier. Application servers such as the Object Spawner, workspace server, stored process server, etc. don’t understand that there is a cluster all of a sudden. Application servers use a configuration file – called metadataConfig.xml – which tells them about the metadata server. So as long as you don’t make changes to this file, the SAS application servers still assume that there is only one metadata server. The SAS middle tier applications keep a list that is automatically updated when the Web Infrastructure Platform web application starts. This is all described in the information for metadata server clustering, which you will find in the resource references in the Appendix of this chapter.
In addition to the official SAS documentation about metadata server clustering, you will find some other great resources such as papers and blogs.
How do clients interact with the metadata server?
When users start a SAS client, such as SAS Enterprise Guide, a connection profile is used to connect to the metadata server. I will talk about Connection Profiles a little later in this chapter.
Metadata Server logging
The default location for the Metadata Server log file is:
SAS-config-dir\\Lev1\SASMeta\MetadataServer\Logs
SAS 9.4 uses a standard logging facility to perform logging for the metadata server and all other SAS servers. Generally, the default logging information are sufficient, as it provides you with information, warnings and errors. SAS Technical Support might ask you to increase the logging level if more precise information is needed for troubleshooting. You can certainly modify the logging levels at any time. Just keep in mind that increasing the information the metadata server writes to the log, the metadata server log file size will grow. Maintaining log files will be discussed further in the housekeeping chapter.
Note: If the reason for considering enabling additional logging is because you want more information for auditing and monitoring, logging will not fulfill your needs. In Chapter 3, SAS Administration Tools, we will talk about SAS Environment Manager, which provides you with some great options for monitoring or auditing.
Important: If you look at the individual log folders for your SAS servers, you will notice that the workspace server does not have any log files. A workspace server log is written for each individual user. Let your users work for a day with a workspace server log enabled and you’ll end up with an abundance of log files. Workspace server logs are usually only enabled when SAS Technical Support needs information for further troubleshooting. Enabling workspace server logging just out of curiosity can affect the performance.
About the Workspace Server, Stored Process Server and all other SAS Servers
These servers are called SAS Application Servers. The SAS Application Servers are a set of metadata 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