BookmarkSubscribeRSS Feed
esjackso
Quartz | Level 8

We are having issues trying to clone our production SAS server virtual machine to make a test server to install 9.4 before pushing it to our main production.

Is there a proper way to do this or suggestions on how to do this?

Just a warning ...Im posting this for our IT dept so if specifics are needed I might have to get that from them.

Thanks!

EJ

6 REPLIES 6
SASKiwi
PROC Star

Have you checked out the SAS 9.4 Migration Guide?

http://support.sas.com/documentation/cdl/en/bimig/63853/HTML/default/viewer.htm#p01intellplatform00m...

If you are taking a "cloning" approach then the SAS Migration Utility would be worth exploring.

I think you will need to be a bit more specific on the problems you are having for others to help.

jakarman
Barite | Level 11

EJ,

All depends on your current business usage, sizing, performance, needed availablity continuity.

There is often made a mistake by many of the "experienced guys" to classify SAS technically as just a better Excel. By that having the idea that replacing some loadables would be the solution for Life Cycle Management.

These days a SAS environment is set up normally as a complex Multi-Tier services way with: Meta-dataserver(s), App-servers (compute), Web (midtier) and a lot of clients(web and thinclients). These clients, all those versions, have relationships/requirements  to server versions. All of those components are communicating with IP-adresses and port numbers. Using duplicate IP-adress names (ports) intended or accidently can cause a lot of trouble.

If your current implementation is small and has low availablity requirements and low integrity requirements you could do the project in the same way as replacing a laptop. Build a new implementation do a big-bang migration, check it and dump the old environment.

For migrating the metadataserver content you can use the SMU utility as mentioned by SASKiwi.

It is not possible to make a snap-shot clone of a production server and restart it on an other VM instance unless you have isolated in a local not direct connected network.  

If your current implementation is big, has high availiblity requiements, high integrity requirements, your project  will become very challenging.

In that case: think of isolating the metadataserver and do a setup in a clustering approach (new with 9.4).

The metdataserver is maintains a metadatabase that is containing als of server-ip/dns names (technical part). Roll-back and Roll forward are new fucntionality with 9.4 at this part. The Smu or dedicated import/export can be used to migrate metadatabase content from the old to the new metadata.

Do you have a lot of SAS-code SAS-data on the current machine? It will need a good plan to migrate that or may be a plan to leaving it in place.

There are notes of peacefull cosexistence off the different SAS releases.  Peaceful Coexistence: SAS 9 and SAS 8.2

By this a more silent and partially moving migration is possible, and no bigbang approach is needed.

The issues (as of the note):
- the DNS/IP adresses and dependicies registered in the SAS-metadatabase are challenged by needing differentiate port-numbers.

- just at Unix (no windows registry involved) it is rather easy to segregate the versions/installations (loadables) by having different mountpoints.

- the connection to identitymanagement RBAC monitoring and logging/reporting procedures are more technical but can also be frustrating.

- this documented "peacefull coexistince" approach is possible too difficult for the SAS support staff.

  The most simple approach they may have is: use the SDW (Software Deployment Wizard) and just enter-enter.....

Todo:

You will need an agreement with those SAS people on the need of your business requirements(policies) and your business needs and than start with a design / plan.

---->-- ja karman --<-----
esjackso
Quartz | Level 8

Thanks for the responses!

Perhaps more specific about our license setup.  Our install is just the standard SAS analytic products 9.3 (see setinit output below), which the 7 or so user remote into the server and start the a sas session as if it was loaded locally with either the standard sas interface or EG. Our license does not allow us to connect through a local instance of EG to the sas installed on the server. So in other words no thin clients, meta, web reporting, or app servers.

The desire is to clone the current VM, upgrade its SAS install to  9.4 and then test key programs to see if we have issues. This way we can address the issues without causing problems for all users at once. If no major problems, then the test vm goes away, we install 9.4 on the production VM and we move forward. If problems exist we figure out the problems in a less "stressful" situation since everything is still running smooth on the production VM.

I still trying to get more information from IT about the issues they are having. Right now all I know is: "Due to the way SAS does their server licensing and that we are running in a VMware environment, my efforts to clone have failed, many times.  " I will post more information once I get clarification.

Proc Setinit output:

CPU A: Model name='' model number='**NCSASPROD1*' serial='+2'.

Expiration:   27FEB2014.

Grace Period:  45 days (ending 13APR2014).

Warning Period: 45 days (ending 28MAY2014).

System birthday:   23JAN2013.

Operating System:   WX64_SV .

Product expiration dates:

---Base SAS Software

                                   27FEB2014 (CPU A)

---SAS/STAT

                                   27FEB2014 (CPU A)

---SAS/GRAPH

                                   27FEB2014 (CPU A)

---SAS Enterprise Guide

                                   27FEB2014 (CPU A)

---SAS/ACCESS Interface to PC Files

                                   27FEB2014 (CPU A)

---SAS/ACCESS Interface to ODBC

                                   27FEB2014 (CPU A)

---SAS Workspace Server for Local Access

                                   27FEB2014 (CPU A)

jakarman
Barite | Level 11

EJ,
This should be a simple situation. It is looking like a shared PC approach by 7 users. running on a Win64 server instance delivered by VMWare. The only complicating issues are the virtualization (VMWARE) and the licensing type. The licensing type you have is a sub-cpacity one. See: 41121 - Starting in SAS® 9.2, a SAS® subcapacity license for a Microsoft Windows operating system is...

Moving to a cloned version will normally also change the computername and thereby making the SAS licensefile unusable. Perhaps more checks are included there (see hyperthreading).
In that case you will need to contact SAS for an other temporary needed licensefile in aspect of the testing on an other vm instance. 

Jaap

---->-- ja karman --<-----
esjackso
Quartz | Level 8

Thanks for the reply!

The interesting thing is our SID file does not reference the server computer name ... it is actually blank. Not sure we have a subcapacity license since when it was first researched it was CPU count that was effecting the pricing (of course this could just have been a mixture of jargon). In any case, I see a call to tech support in our future, either for a limited use test SID file and / or guidance in setting this up.

If anyone else out there has done this successfully we would still be interested in hearing the process you went through.

Thanks!

EJ

klaus819
Calcite | Level 5

EJ,

You can verify that you SID isn't tied to you computer name.  Windows has the ability to support multiple NetBIOS computer names.  If you are comfortable with editing the Windows registry you can add an OptionalNames string value to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanServer\Parameters section.  Once the key has been added you can set the value to the production server's name.  To test this requires that you stop the existing production VM and alter the DNS entry to point to your new VM.  I have used this in a cold spare scenario to replace a failed compute tier server in a three tier EBI platform.  SAS never complained.

Vic 

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

CLI in SAS Viya

Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 6 replies
  • 2648 views
  • 4 likes
  • 4 in conversation