Running two SAS Environments on the same Linux machine

[tommy81]

Hi,

We are trying to find the best practice on deploying the same version of SAS 9.4 on the same machine to create 2 seperate envirnments i.e QA and SIT. From what I could read on SAS papers is that creating 2 seperate Metadata servers and using the SAS Migration utility is a possibility.

What are the other options ?

Another question is what are the pitfalls of this approach ? Where all will there be potential conflicats like ports.Performace trade off .

Any insight or reference to these would be great.Thanks in advance.

[PaulHomes · Accepted solution]

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 (for QA) and then run it again to do another deployment of Lev2 (for SIT). 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. With SIT and QA it may not be an issue but 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.

Others may have some additional thoughts for you to consider.

[tommy81]

This is very helpful information Paul.

On similar lines , what if I want to take the Metadata and other components (TBD) from another 2nd phycial server , and import it to this dual server machine ? Can we still follow the same procedure . 

[PaulHomes]

No problem.

Yes, you can either 1) use the SAS Migration Utiliity to create a package from the other server and use it during the SAS Deployment Manager deployment on the new server or 2) use the SAS Deployment Manager to install-new on the new server and then export SAS packages from the other  server to import into the new server.

[PaulHomes]

I should also say that these are high level steps. If you haven't seen it already, I'd strongly recommend you read the SAS 9.4 Intelligence Platform: Migration Guide. Additionally, if those environments are important to your business then it's well worth getting help from SAS Professional Services or a local SAS Partner who have lots of experience in doing migrations.

[ronan]

Paul has perfectly summed up the rationale for deploying the two env. into a single physical machine - let's say platform since your installment could be deployed on several machines depending on your topology. 

Another option to consider, if compatible with Business/IT Rules and SLAs, would be to create your environments logically inside one single metadata instance using LDAP authentication, SAS security tools combined with OS security :

•  agregating the LDAP directories or Groups if necessary  (https://support.sas.com/documentation/cdl/en/bisecag/69827/HTML/default/viewer.htm#n0w8oa3erw568vn19...)
• SAS metadata security (ACTs, distinct Custom repositories , distinct SAS execution contexts or "SAS Application contexts" )
• SAS lockdown options (whitelist of system folders that can be accessed by some group of users / some SAS component servers) or metadata-bound libraries
• system account and folder permissions if necessary

Pros :

* The administration overall cost is smaller since you have only one instance to manage instead of two.

* The promotion process is - should be - simplified since the XML package might not be necessary, using only copy 

* The "version control" process - always difficult to set up with SAS products (only partially compatible with standards like SVN or GitHub) might be easier  since you can trace more finely the changes between environment (single log files, single metadata requests) . Even though the lifecycle reporting would still remain difficult : eg how could we "version" a stored process whose code is stored in metadata ?

Cons : 

- the installation cost is definitely higher since this kind of architecture heavily relies on customisation and high end technical knowledge. Lev1 / Lev2 by comparaison is more straightforward and simpler to install, closer to Out Of The Box installations that everyone with a tinge of SAS administration skill can understand . The corresponding documentation/training effort would be higher also.

- not compatible with some (fairly basic) IT rules since SAs MidTier in this case - one single HTTP server, JAVA Web App server etc.-  cannot be kept separate if underlying networks are distinct

- as Paul says, and even more with this logical multi-tenant architecture, sizing would require some more attention : JVM HeapSize, Metadata MemSize etc.

[SASKiwi]

In addition to the valuable insights of @PaulHomes and @ronan:

In my experience running multiple SAS environments on the same server (Lev1/Lv2) is very common and is almost the defacto standard for small to medium-sized SAS installations. The primary reason for this is the SAS licensing model. Running more than one SAS environment on the same server doesn't cost you any more than having a single environment. Having separate physical servers will. This is usually only an option for large SAS sites with large software and hardware budgets.

Also if you need DR capability, you can mirror your Lev1/Lev2 setup on a DR server that is on warm-standby. This again does not increase your SAS licensing costs as this is covered in your SAS licence terms and conditions.

I would also echo the fact that Lev1/Lev2 setups are generally easy to support and maintain. I've never yet experienced having to apply a critical SAS fix so then the downside of having just one SAS installed image is in my view minor for small to medium SAS sites. 

[tommy81]

Thanks for bringing the DR server in picture.

So hypothetically during a DR event ,ehat I understand is we would attach the PRD-DR replicated disks to the machine which has 2 environments say DR/SIT.

So if the PROD env has LEV1 and DR has LEV2 , it would create an issue rt. They must always be at the same level to fuction seamlessley in a DR situation .Please correct me if wrong .