Can DNS Alias name can be used for accessing SAS Applications(Web and Client)?

[SangramjitPanda]

Hi All,

We have SAS 9.4 M3 Servers installed on 3 Linux boxes.

Metadata Tier : Linux Box 1

Compute Tier: Box 2

Web Tier: Box 3

We are thinking to create DNS alias names which will point to same IP address as by above Linux Box hostnames. Below are my concerns:

1. Can we use the DNS alias created for Metadata Tier in the SAS EG profile instead of using the metadata server hostaname for connecting to sas server ? Will it work

2. Can we access the Web URL's for SAS Studio and SAS Stored Process Web applications by the DNS Alias name which we created for WEB Tier Server instead of actual Web Tier Host name url's? Will it work

I mean to access http://DNSAlias.server.com:7980/SASStudio instead of http://WebTierhostname.server.com:7980/SASStudio ?

Thanks,

Sangramjit

[PaulHomes · Accepted solution]

Yes, you can use DNS aliases (CNAMEs) to refer to your SAS servers. I have done this several times in the past. It can be useful when you want to use meaningful logical names when the servers have obscure physical names, or when you want to have the option to easily switch from one SAS platform to another (during upgrades, DR etc). For best success you should plan carefully and get help from SAS Professional Services or a local SAS Partner if you are not confident. Using aliases is more easily done during SAS installation/deployment but can also be done post-deployment. Some things to consider:

• Are you doing this just as a convenience for users/clients or for servers to communicate with each other too?
• A SAS app/client/server will often get a host name from metadata/config for the client to use for subsequent connections (you will see this with the web apps) so, for consistency, you may want/need to use the DNS aliases in metadata/config too. e.g. see Overview of Updating Host Name References and Specifying Connection Properties.
• If you are using IWA / Kerberos you will want to make sure you add Service Principal Names (SPNs) for the aliases as well as the actual names.
• If you are using SSL/TLS then make sure your certificates include the DNS aliases as Subject Alternative Names (SANs) as well as the actual names (unless wildcards will suffice).

[SangramjitPanda]

Thanks Paul for your quick response and confirmation.

Sorry for the delay in response.

Here are the below answers for your previous posted questions:

1. Yes the intention here is just to use the DNS alias name in Client Profiles (EG). Actually in near future we are planning to Install SAS 9.4 M5 on new linux boxes and currently we haven't created DNS aliases for existing servers too. So I am planning to create DNS aliases for existing server and use the DNS aliases in the Client Profiles so that when there will be new SAS deployment, I can just switch the DNS aliases to point to new linux boxes.

 a) Is this the right approach?

 b) Whether using the DNS aliases in Client Profiles requires any sort of configuration changes from Server side?

2. Mostly the use of DNS aliases will be used in EG profiles and we do have web apps like SAS Studio and SAS Stored Process.

Do any configuration changes or Updating Host reference is required for using DNS aliases while accessing above web apps urls?

3. We don't use IWA / Kerberos  

Thanks,

Sangramjit

[PaulHomes]

From what you have said it sounds like aliases may work for you on the client, without any server configuration, as long as:

• the clients will still be able to resolve any real host names that get returned from the servers
• you are not using HTTPS for the mid-tier (where you may otherwise get cert errors unless the certs also include the aliases as SANs)
• the web apps will most likely redirect the clients to use the real host names after the initial connection

Otherwise, you may need to do some server side re-config to get it to factor in the aliases too.

Best thing to do is to try it out in a dev/test/playpen environment. I would do a quick test myself except my environment uses TLS and the certs only have the real host names.

[SangramjitPanda]

Yes, for testing purpose I had requested to create the DNS Aliases on TEST Server and then used those references in Clients and it worked fine.

- Provided the DNS Alias of Metadata Tier in EG profile and tried to connect, it worked

- Tried to access the SAMBA Drives using the Compute Tier DNS Alias name, it worked

- Tried to access the Web Apps (SAS Studio, SAS Stored Process) URL's using Web Tier Alias name, it worked but it got resolved to actual server name. Is it possible not to resolve to actual server name while accessing web apps using aliases? 

Do you foresee any potential disruptions to users while using DNS aliases?

Did some above basic validations, are there any other validation that need to tested out using DNS aliases?

Thanks,

Sangramjit

[PaulHomes]

It's good to hear your testing went well. If you want the web apps to use the aliased in redirections (instead of the physical host names) then that will require some server changes as mentioned in my first reply -  see Overview of Updating Host Name References and Specifying Connection Properties. If you only want the clients to see the alias then you could look at the external connection properties. If you want the server side components to use the aliases too then go through a host name change process.

In the past when I have used DNS aliases to provide the ability to switch between primary and DR sites I also made sure the primary and DR sites always saw themselves with the aliases so they never tried to interact with each other regardless of the state of the client DNS resolution (you can use static /etc/hosts mappings on the servers or split-horizon DNS depending on how complex your environment is)

Using DNS aliases there is the potential for disruption after changing the DNS alias definitions due to caching and propagation lags. If you want to avoid this then you could look at IP switch features instead. I remember a discussion of this in an old SAS Global Forum 2011 paper (358-2011) "Considerations for Implementing a Highly Available or Disaster Recovery Environment" by Diane Hatcher and Jochen Kirsten. As that paper is several years old now you might want to talk to your network admins to see what the current best practices are regarding rapid host/IP switch-over capabilities.

[SangramjitPanda]

Thanks Paul for sharing these links. Will go through the links and will post if there are any challenges.