BookmarkSubscribeRSS Feed
japsas100
Pyrite | Level 9

We are using SAS 9.2 on AIX. We have one application, one WebSphere middle tier, and one database server. We are migrating the servers from one location to another location without any upgrading the version/OS/ except hostname and IP address.

 

First issue, We have a shell script where the server name is hardcoded in most of the shell script(sas prog is calling within shell script).If we are updating server name then we need to make changes in all the script because we getting server name with uname -n command and on the basis of server name we are defining the libraries for Dev and prod env.

 

Second Issue, After copy all the config files from the old to the new server we have updated the hostname with sas deployment manager. We noticed there is no issue with the app server, However in Websphere, I can see a lot of manual steps are required to update the hostname with WAS Admin Console as per file generated by SDM ChangeHostName_xxxx-xx-xx-xx.xx.xx.html file I do understand manual steps are very tricky and some time issues do not resolve after spending lots of time in troubleshooting.

 

Possible Solution without changing the Host-name

Now we are thinking to change the host file by adding the old hostname entry against the new IP address and adding CNAME records in the DNS for the old server names .

For example.... 192.168.1.0 | new_alias | new_server | old_alia | old_server

 

Do you think this solution will fix both the issue ? All the changes should done at network level and we don't need to run the SDM to update the hostname because both old and new hostname is added to etc/host file with CNAME records in the DNS for the old server names 

 

Any suggestion is much appreciated!

7 REPLIES 7
Kurt_Bremser
Super User

Why don't you use the opportunity to do the right thing?

  • upgrade all software to current level, from the OS to the whole SAS package. I won't even start to name the improvements you'll find in 9.4M7
  • set up a completely new environment from scratch, and deal with all the issues you already noticed one-by-one, like putting things in scripts that can change into environment variables
  • switch your users over to the new environment once it's tested and verified

I have done this several times, and every time it ended up with great improvements in usability and maintainability.

JuanS_OCS
Amethyst | Level 16

Hello @japsas100 ,

 

I fully understand your situation. I agree with @Kurt_Bremser that a full migration would be ideally the best way to go, but I also understand this is a lift-and-shift operation, and SAS supports that kind of operation.

 

To be honest, the manual changes it is what is supported by SA Tech Support, therefore if you want to be fully supported, try to be coherent and follow the guideline. Of course, you can apply those manual steps by automating the read of that html file and using patterns, but that is up to you.

 

Anything else, will not be officially supported, and if you have further issues, you might find trouble with support.

 

This being said, there are some components you need to mind, in any case:

 

- IP addresses on your network interfaces. Hopefully you will have only one.

- hostname (short and fqdn)

- aliases (hosrt and fqdn)

- domain name

- the mappings between hostnames/aliases with the IP (or IPs / network interfaces)

- multicast IP address

 

Those are the items you will need to mind, inside your server variables and configuration files, and in your network.

 

If you cannot feel fully confident, I would personally take a holistic approach: a)update the hostnames (hostname update tool + manual changes) as best as you can, b) plus the workaround the server+network config approach. Once done and you are able to fully validate the new system, you can start lifting network/hostnames to the real ones and keep validating until all is as it should be. Only this way you can ensure a quick delivery, but also to minimize/filter possible issues in the thousand of configuration files within middle tier.

 

 

rabindrakumar1
Obsidian | Level 7

Hi @japsas100 

 

I agree with @JuanS_OCS inputs.

 

These changes are really tricky and most preferbably everthing and anything can't be done in automatically.

For these kind of changes it is advised to perform such tasks manually inorder to validate and test the commplete funcationalities on each servers may be Web, Meta and Compute.

japsas100
Pyrite | Level 9
Thanks!

The decision to upgrade sas is not in my hand. Scope is limited to change IP and host name if new servers.

What your thoughts if we include both old and new hostname in host file will sas and adding CNAME records in the DNS for the old server names.
For example.... 192.168.1.0 | new_alias | new_server | old_alia | old_server

With this solution , there is no change at sas level. Will script pick the old server name in with u name -n?

The reason we are doing this exercise because we have large no. of shell script and sas prog where we have hardcoded old host name.
Will this work,If we concatenat old server hostname and old hostname alias link to new server IP. In new env, each server has only one IP address.
JuanS_OCS
Amethyst | Level 16

I must insist, please mind that if you do this, the change probably will not be supported by SAS Tech Support, you would be on your own.

 

This being said, again, assuming you have just one network interface, it might work for many components, but I cannot ensure it will work completely. The more tiers and more complexity, the lower probability it would work. Multicast is something that can give you headaches. Firewall rules as well.

Anand_V
Ammonite | Level 13
Starting point for more troubles and TS tracks? If SAS has been configured with host-names and as long host-names are resolving technically it should work but as advised by other experts it can be tricky and TS will not be able to support on this. I would also suggest for a clean migration approach rather than workarounds.
jcFranklin
SAS Employee

@japsas100 

 

Just to piggy back off what others have commented on, you might want to consider upgrading your SAS version to the current version. Not only will you have more software enhancements, but your site will also still be fully supported by SAS Technical Support after Jan 1st, 2021. 

 

Per the new Support Services and Policies "Support Services for Current and Prior Releases of SAS® Software" SAS 9.2 will be moving to limited support starting in 2021. Limited Support activity by Technical Support Staff:

 

"Provides fixes where they are already available. This support also includes the clarifying documentation (including self-help resources*) and instructions for applying fixes as well as answering questions about upgrades.

 

This support lasts until the software product is retired."


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 

Get Started with SAS Information Catalog in SAS Viya

SAS technical trainer Erin Winters shows you how to explore assets, create new data discovery agents, schedule data discovery agents, and much more.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 7 replies
  • 1697 views
  • 4 likes
  • 6 in conversation