Before porting your Unix apps to Linux, set up a sandbox to serve as a playground for testing. Skimping on app...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
testing can harm your development and prototype-production environments, warns Unix-Linux systems consultant Ken Milberg. In this tip, a Unix-Linux migration expert describes the steps and considerations involved in porting Unix apps to Linux.
What are some indications that an IT shop running apps on 32-bit servers should consider moving to 64-bit servers? Can you offer some best practices when moving apps up to 64-bit servers?
Ken Milberg: The question to ask is, how are your applications running? Are they experiencing performance problems? Are you looking to scale upwards to a larger system or possibly run more applications on that server? If everything is functioning normally, then I wouldn't try fixing something that isn't broken. If the hardware and, possibly software, versions are about to go to expire, then it may be time to move on.
The fundamental question here is: does your application support running on 64-bit hardware and a 64-bit version of the operating systems kernel that you would be using? It is not a trivial undertaking to port software from 32-bit code to 64-bit code. You'll need to contact your vendor and find out these answers. You will also need to confirm that all applications running on the box are supported on a 64-bit kernel. Why would you want to move to 64-bit hardware and use a 32-bit kernel? If you are using a host monitoring tool like BMC Patrol, or backup software like Tivoli, you will need versions of software that support a 64-bit kernel.
Regarding best practices, I would create some kind of sandbox environment to perform all your testing in. Assuming all your applications have fully supported 64-bit code versions, find an appropriate hardware platform for your testing and get to work. There are no short-cuts for this type of work. You do NOT want to be touching your live systems, prior to you completing a Proof of Concept (POC) for the 64-bit migration.
What personnel training is needed for IT shops that are porting their Unix apps to Linux?
Milberg: It depends on several factors. What is your staff using now? Is it Windows or Unix? If it is Unix, your learning curve will be lower than if it were Windows, since Linux is similar to Unix. There are classes that are designed for Unix administrators learning Linux that will focus on what Unix admins will need to know to administrate Linux systems. Essentially, Windows people will be starting from scratch. Either way, I would send them off-site to training classes because I'm not particularly fond of on-site training as your staff will be running in and out from training to fixing production problems.
The type of training will hinge on which Linux variant you will be choosing. Though the actual Linux kernel may be the same, the interface and management utilities will be different. Some training centers focus more on Red Hat than SUSE and vice versa, so you will want to make sure you are being trained on the same Linux you will be using. Make sure the version is the same, as well, due to substantial variations between versions. For example, there are many differences in how to do Logical Volume Manager (LVM) related tasks with RHEL3 and RHEL4. If your application does not support RHEL4, why take a training class in RHEL4?
What factors need to be considered when creating a porting schedule?
Milberg: Regarding a porting schedule, again this revolves around the type of applications you are porting, what you are porting from, how many environments you will be porting, etc. As a general rule, I'm a big believer in doing a Proof of Concept (POC) prior to implementing an all-out migration. If a vendor is selling you migration servers and hardware, let them pick up the tab for a POC. If not, do it on the cheap.
Can you offer some advice on setting up an environment for porting Unix apps to Linux?
Milberg: It is important to perform the appropriate capacity planning, in order to architect a system that will be able to support the current Unix workloads you are using, without over-architecting a solution. Here are some tips:
- Try to use industry standard benchmarks where possible in doing this.
- The environment should come with suitable compilers that will allow you to recompile programs.
- Don't be shy with providing extra disk space to the environment, since you will be making adjustments.
- Ask questions of your ISV regarding best practices for Linux configurations. Your ISV should be a big asset to you in your migration. Make sure there are customers already using their Linux based software; don't be the guinea pig!
- Don't forget to train your staff in Linux. There are enough differences between Unix and Linux to warrant training. If possible, buy support from your Linux distributor, as there will be issues that come up that require escalation.
I would also suggest setting up multiple environments, including a sandbox where you may play around without harming your development and prototype-production environments.
What can be done to preserve the functions of platform-specific, Unix apps if they have to be ported to Linux?
Milberg: The purpose of platform-specific features are usually to optimize the environment on the hardware that it runs on. I'm not aware of any tool that will allow you to preserve those kinds of functions when porting to Linux on another platform. The only way to get around this is by using hardware that supports Unix, Linux and certain functions on both platforms. IBM is an example of a company that does this. It provides for Advanced Power Virtualization features on both Unix (AIX) and Linux (RHEL4 & SLES9+) running on it's p5 servers. This is because IBM enhanced the kernel on both operating systems to provide for the common functionality, which also allows for the sharing of processors between separate Linux and Unix partitions.
It is generally considered good programming practice NOT to use platform-specific features when writing code, in order to limit the amount of problems when porting to different architectures. To further answer your question, I would need to know more specifics about the application that uses these platform-specific features. My guess is, that you won't be able to preserve much.