Regarding :: Movement of SAS Mid tier Movement across Linux environment

[keds]

Hi All ,

we are in process of moving SAS Application from one Data Center to another. we are planning as ( Pls note we have three tier installation )

1) shut down all the services from Metadata / Compute and Mid Tier .

2) Take backup of file systems on which SAS was insatalled for metadata and Compute and mid tier servers.

3) Restore Metadata and Compute tier and make changes to affect new datacenter environment.

Now Questios :

1) if i dont restore the mid tier environment , and run the deployment wizard from software depot and perform install and config of mid tier only as there is no customization of EAR files. will there be any entry made to metadat server ? my concerns is since we have bought the metadata from old environment and again installing and configure mid tier will it again mess up with the metadata entries?

Has anybody experienced this ? would be great if you could give your advise.

2) can we just copy the APPDATA folder and Config path folder from old environment to new environment and run the deployment wizard to reconfigure it to the new datacenter ? can we do this ?

Any links thoughts from anybody would be greatly helpful.

Thanks

Keds

[Mark_sas]

Have you considered simply unconfiguring/uninstalling your mid tier from the source environment, cloning (or migrating via the SAS Migration Utility) your meta/compute tier onto your new environment, and finally doing a fresh mid tier deployment as an add-on to your new environment?  You might find the information at http://support.sas.com/documentation/cdl/en/bisag/67481/HTML/default/viewer.htm#p1gs13ueroyethn11y3t...

useful if you end up going the cloning route.

- Mark

[keds]

Thanks  Mark@sas. But this is for SAS 9.2.

Other point is we dont want to disturb the exisitng source environment as we want it to continue for some months till users get confidence on new migrated environment. so doing anything in source is not an option.

But to my main moot questions,

will installing and configuring Fresh metadata update the metadata configuration and settings ?

or

Will just copying file structure and files ( APPDATA / CONFIG Path)  form old environment will do the magic with some re configuration ?

[Mark_sas]

1) You're in unsupported territory here.  As you suspect, moving over your metadata/compute tier, but not your mid tier, brings with it metadata supporting your mid tier.  If you then try to install/configure a brand new mid tier as essentially an "add-on" to this environment, there's no guarantee the original mid tier metadata won't get in the way of the new mid tier deployment.

2) Unfortunately, this is also unsupported.  Moving deployments by copying configuration directories from one machine to another is not a valid approach for 9.2, 9.3, or 9.4, unless you're doing full cloning.  As an aside, the equivalent previously mentioned doc for 9.2 is http://support.sas.com/documentation/cdl/en/bisag/64088/HTML/default/viewer.htm#a003361854.htm

[LeeHerman]

What are you trying to accomplish/avoid by not copying the whole environment, including the mid-tier? Could the changes you want be made to the copy of the mid-tier once it is up in the new location?

[keds]

yeah ,  @LeeHerman. We are trying to ascertain pros and cons of having the mid tier also copied. Since we are not moving

IBM web sphere and installing in the new environment. We thought that installing mid tier components will synchronize with the new installed web sphere.

we feel that if we just copy the mid tier components we might end up taking more time in trouble shooting rather than installing and configuring which automatically synchronizes with my web server and also deploys.

But as said above we have a concern that this install configure might mess with the old metadata brought from old environment.

@ Mark@sas : since linux stores everything at file system level, isn’t cloning and copying/replicating install and configuration directories mean the same? Apologies if I have written something very naïve.

[Mark_sas]

You're right.  Cloning does indeed equate to copying files on a UNIX system.  My earlier responses was related to the suggestion of simply copying a subset of directories ("APPDATA / CONFIG Path") to your new midtier, and then performing some form of reconfiguration to get it working.  I should have been more precise in my response.  Doing those activities alone will leave behind important files (e.g., those in your installation directory - a.k.a. SASHOME).  On the other hand, if you make sure all files related to your SAS environment are replicated in the same locations on an equivalent system in the new data center, including installation and configuration directories as well as any other directories to which you pointed during configuration (e.g., third-party software locations) and modified operating system files (e.g., init.d)

you're essentially cloning your environment, and would make your target system a candidate for the Update Host Name option (assuming you've got a new host name).

[jakarman]

Keds the way sas is installed and configured is not conforming any common known standard at Linux or at windows or at z/os. We could go into a discussion with mark@sas why sas is not following those common approaches it will not help you.

You do not have a rpm red hat package manager approach, you don not have common "standard ofgood practice" settings for your high privileged keys etc etc.

The sas Installation is having his own invented installer based on XML file processing. When using that a lot is placed in configures and the sas metadata base.

Changing and maintaining those is not easy. A lot is documented it should be possible. The statement of mark@sas it is not supported would imply sas would not be a fit with a lot of mandatory guidelines.

Could you work with segregated network segments as being used for testing acceptance of the new machines you are in a often used d/r approach. Full copy of the whole environment including top names and same type of machines.

Are you migrating machine types than you can better go for a release update proposal 9.4 where clustering is possible.

The problem is shifting to use the same business data and same business programs for sas processing

That is an other question being to be solved