BookmarkSubscribeRSS Feed
🔒 This topic is solved and locked. Need further help from the community? Please sign in and ask a new question.
Neetu
Fluorite | Level 6

Once the image is active(from infrasture/os related perpective ), the next task was to make SAS on that system up

So I used utility provided by SAS : Change host name utility in the SAS deployement Manager

And changed the hostname in my SAS files (configuration,xml,.bat etc. ) from box01 to boxd01.

once this process is complete i followed the additional manual steps mentioned in the changhostnamesummary.htm file as well had done
a thorow search on my filesystem(windows os) to find old host name references and changed them manually.
(Except the log file, initial installation configuration logs,reports.)

Once this was done , i started my metadata server and ta da.. it was up and now now running on boxd01 .

Next step was doing the same process of changing host name on compute and web tier and follow the manual steps.

there were few changes like changing the hostname in windows regisrty files for LSF ,Process Manager as well.

Note : if the system had additional ObjectSpawner , connect spawner etc. configured then one must reconfigure them in order for them to work.

So once my boxd01 was ready and all services were up, I repointed my DB connection to new DB's and fired SAS sessions and now i have

two boxes: box01 and boxd01 with same SAS configuration.

We have run all possible SAS jobs's that we have on box01 on the new box, including the extracts via powershells,python,curl jobs and all seem to be
working as expected.

Thus now my box boxd01 is now ready for upgrade to new relaease of SAS and our day to day activities won't be affected.

To Summarise
Step 1: The live system(box01) was paused and a full snapshot backup was taken
step 2: this Snapshot was installed on a new box : the infrasture/os team made sure that except the host name all settings from network,
security, group policies etc. were exactly same as box01
Step3: Run the change host name utility on each machine (meta->compute->web) and perform the manual steps as indicated in changhostnamesummary.htm file
Step 4:Start SAS , and check logs for errors warnings, rectify and restart
step5: run jobs , flows , stp's , view applciations and perform day to day operations.
Step 6: IF step 4 &5 go well, then a new box is ready for upgrade with same level of settings as actual box, without hampering the day to day work.

 

My new box is working very well is after a rigourous testing on the system ,we are doing upgrade.

 

1 ACCEPTED SOLUTION

Accepted Solutions
Neetu
Fluorite | Level 6

I have done it for SAS 9.4 M2 T SAS 9.4 M4

View solution in original post

6 REPLIES 6
SASKiwi
PROC Star

Nice to see this can be done. What release and maintenance level of SAS did you do this with?

Neetu
Fluorite | Level 6

I have done it for SAS 9.4 M2 T SAS 9.4 M4

JuanS_OCS
Amethyst | Level 16

@Neetu, and those deployment where including middle tier? What components/solutions? Meaning:

WIP, Shared Services, Environment Manager, EVMDM? Single Sign-on, SSL? BI, EBI, EDI, DM, VA, ...?

JuanS_OCS
Amethyst | Level 16

Hello @Neetu,

 

nice description, I am sure it will help many others to get ideas.

I followed similar processes for quick deployment of SAS environments (not all SAS v9 Solutions would support standard processes though, some require extra attention, which is fine, btw), since sometimes I had to deploy > 30 servers in less than 1 month, and all of them including certain corporate standards.

 

Perhaps if you could rewrite the post and add some images/graphs, it could be proposed to be included in the Library 🙂

 

@SASKiwi, from my experience, if it helps to cover your interest, I have been doing similar stuff since SAS 9.1.3. And all the improvements with virtualization and the improvements in the SAS platform (9.2, 9.4, 9.4) it has become a bit easier, at least for the most basic solutions. Certain SAS solutions, as previously said, it makes more challenging this process, and I would say, the more complex the SAS solution, the more it is worth to create a brand new installation.  

 

@Neetu, I feel curious: have you applied this process on SAS 9.4 and with deployments including the Shared Services database (WIP database) ?

SASKiwi
PROC Star

@JuanS_OCS - thanks for the expert advice. It is also good to get an independent view on installation best practices. Lately we have been using consultants from SAS and they have always installed from scratch, even when mirroring an install for Disaster Recovery. Perhaps they do it that way because it is the way they have been taught?

JuanS_OCS
Amethyst | Level 16

Hi there @SASKiwi,

 

well I believe it is all about roles, knowledge of architecture (dependencies/integration) and the final quality you can ensure to deliver.

SAS 9 is not anymore as the previous versions: a lof of components, from diferent vendors, specially on the middle tier. 

That's why my especific question to @Neetu. And now basically every SAS solution is based on the middle tier. Therefore the more complex the solution also the more complex the middle tier is, architecture and integration-wise. Have you seen the huge amount of config files involved in the middle tier? 

 

The best practice to ensure good quality is always to install from scratch. I think there is no question there. And the fact, as software vendor and owner, needs to follow the best protocol avavailable to deliver good quality. Only what is groovy-script managed would be officially supported by Technical Support. Any deviation from certain standards will exponentially reduce the amount of support you could receive (even to SAS-internal consultants)... simply because less people would be tecnically skilled to support deviations. SAS Technical Support sometimes helps even with deviations... but we cannot count on that, because of the reason explained above.

 

Please note that I am not part of SAS Technical Support, therefore please do not consider my opinion/perspective as their message on the subject. It is an individual perspective/experience.

 

All of that said, the SAS software is bought by you and it is up to you to decide the boundaries of support you are willing to accept (or reject). If with your skillset you are capable to ensure an acceptable level of quality with deviation of standards, that means one excellent thing: the SAS world will benefit from additional knowledge, and perhaps SAS will include the practice as best practice if you can share your knowledge as SAS user through a good paper/presentation.

 

And that is somehow something that is happening with SAS Viya: SAS made a huge effort by including the SAS deployments into IT standards and best practices, by creating modules of the software and the services (microservices) are enabling quick deployments thanks to Ansible.

 

My personal takeaway is that I will be able, finally, to focus more on the things that matter the most to me, such as the architecture and actual maintenance of the platforms ( to design and maintain the quality of service I want to deliver ), rather than on the deployment itself (or re-inventing the wheel to make quick deployments of SAS 9). Things are becoming better 🙂

 

 

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
  • 1819 views
  • 7 likes
  • 3 in conversation