Draft linux Migration Criteria and Strategy Guidelines September 15, 2003



Download 20.07 Kb.
Date31.01.2017
Size20.07 Kb.
#13447
DRAFT
Linux Migration Criteria and Strategy Guidelines

September 15, 2003
[Please send comments, suggestions and questions to dennis@stanford.edu]
Overview

This document discusses the migration of TSS applications to Linux, suggests some criteria to use in determining the suitability of an application for migration, and identifies short-term, medium-term, and long-term migration opportunities. This document also suggests a strategy and a migration methodology.


Summary of Key Issues:

There are four areas to consider: acquisition, migration, operation, and support.


Acquisition:

One of the biggest factors driving a Linux migration in industry is the cost savings associated with replacing expensive Sun proprietary hardware with cheaper Intel-based hardware. Not only are Intel platforms less expensive than Sun platforms, but they are much faster as well, resulting in fewer servers and fewer CPU-based software licenses.


The software cost differential between Linux, Solaris and Windows is not clear and requires close analysis in each migration instance. Both Solaris and Windows cost money, and although Linux itself is free, many key applications like Oracle require Red Hat Enterprise Linux, which is not free. Several industry studies have indicated that in general, Linux license costs are lower than Windows, but a lot depends on the specific application.
Industry Trends to watch:

  • Sun has been dropping hardware costs on low end servers, and is further developing an Intel based Solaris.



Migration:

The two main considerations are the costs and the risks of the migration.


There are one time costs associated with a migration to Linux and each potential migration must be considered carefully. One of the biggest expenses is the cost of retraining system administrators. Other costs include code that must be rewritten, data that must be migrated, integration work, licenses, and new software that may have to be purchased.
However, these costs can be minimized if the migration to Linux occurs when a migration would have taken place anyway, such as the end of the amortization cycle when new hardware is acquired, or when a new application or a new release of an existing application is deployed.
The risks to be considered include:

  • Security: can the new platform be as secure as the old? Are there any new processes or procedures that must be put in place to ensure security?

  • Client disruption: how smooth with the migration be? Will services be disrupted? If there will be a disruption, what will those costs be?

  • Infrastructure costs: will there be additional infrastructure service demands that need to be taken into account?


Operation:

Operational savings depend on how extensive the migration is. The wider Linux is adopted, the lower the operational costs. Adopting Linux as just another OS and running it side by side with Windows, Solaris and AIX is the most expensive solution.


The most effective operational setup would be to adopt Linux on a wide basis and deploy an enterprise Linux management package. This would enable management tools and personnel skills to be leveraged across a wider target, increasing efficiency and allowing a Sys Admin to support more machines.
Support:

We recommend using a mixture of purchased support for critical servers, using internet community help for other servers, and developing in-house Linux expertise. Future cost studies will determine the actual costs, but industry sources indicate that Linux support will be no more expensive in the long run than present support models. An additional factor is that Solaris and Windows are proprietary and problem solutions can only come from Sun and Microsoft, whereas Linux solutions can come from a wide variety of sources. See TSS Linux Support Options.



Migration Criteria Guidelines

The following are general criteria to consider when evaluating an application for migration suitability. The criteria are not exhaustive, nor do they cover unusual conditions or circumstances. The evaluator should gather as much information as possible, and try to understand the application - how it works and how it interacts in the computing environment. The ideal situation would be to follow the migration methodology (platform evaluation, pilot, test, pre-prod, production), and carefully evaluate the results from each step before proceeding to the next.


Some ITSS applications that we already know run under Linux:

  • Oracle (Red Hat Advanced Server 2.1)

  • Autosys 4.5

  • Peoplesoft (release date Dec 2003, on Red Hat Advanced Server 2.1)

  • Apache web server

  • Tomcat

  • Sendmail, IMAP, POP

  • DNS

Criteria:



  • The migration cost should be the same or less than the cost of staying on the current platform. Some criteria to consider are performance, supportability, integration, hardware, software, hardware maintenance, software support (both OS and application), software licensing, migration costs, server consolidation and training.

  • The application should run on a TSS supported version of Linux, and ideally have a roadmap for regular development on that version. A static application (an application that will only run on a single version of Linux and cannot be moved to more recent versions) will cost more over time since it will continually require special handling and care.

  • The application must be compatible with and adaptable to our infrastructure (Authentication, DNS, load balancing, firewalls, directory, etc). Applications that are ‘special cases’ cost more to support, not only in Linux, but UNIX and Windows as well.

General questions:



  • Why migrate to Linux? What is the business logic for the move?

  • What is the architecture of the servers running the application or service? A diagram or picture would be very useful.

  • What are the software components on each server?

  • Will it be a complete or partial migration? If a partial, will the parts still interact after the migration?

General software questions to ask:



  • Can the application run on Linux? If so, which version of Linux is it certified on?

  • Does the application require any special modules that are developed independently of Linux that might cause problems with future releases?

  • Does the application require any modifications to the kernel?

  • Does the application use any kernel features that might change in a major release?

  • Does the application use standard protocols, or proprietary protocols? How are the proprietary protocols supported?

  • What is the licensing model for the software?

General hardware questions to ask:



  • Does the application require any special cards, and do these cards have Linux drivers? What are the release dates for new versions of the drivers? Are they kept up to date by the vendor? Will there be an issue for future versions of Linux?

  • Is the application memory intensive or CPU intensive? If CPU intensive, will the faster CPUs of an Intel platform mean fewer machines?


Some Dell Suggested Hardware Equivalencies


Sun E6XXX 12-20 CPU/16-32 GB RAM

Dell 8450 8 CPU/16-32 GB RAM

Sun E4XXX 4-8 CPU/2-16 GB RAM

Dell 6650 2-4 CPU/2-16 GB RAM

Sun E3500 4-6 CPU/2-8 GB RAM

Dell PE 2650 2 CPU/2-6 GB RAM

Sun E450 2-4 CPU/2-4 GB RAM

Dell PE 2650 1-2 CPU/2-4 GB RAM

Sun E420R 4 CPU/2-8 GB RAM

Dell PE 2650 1-2 CPU/2-6 GB RAM

Sun E280R 2 CPU/4-8 GB RAM

Dell PE 1650/2650 2 CPU/4-6 GB RAM


Migration Strategy
Our approach to incorporating Linux into our environment will be to draft a migration plan that includes a high-level work plan, training plan, and other considerations such as resource allocation.
Phase One (Aug-Dec 2003): “low hanging fruit”: easy to migrate, low risk

  • Web servers (the HARP project and the HATS project are using Linux Web servers).

  • Email servers (Webmail, smtp and email routers).

  • Web servers (the WWWs).

Phase Two (Jan-June 2004): “climb the lower branches”: medium difficulty, medium risk



  • New applications that have been developed on Linux

  • Servers coming off amortization

  • New client upgrades

  • Load balanced Web farm

  • Internal infrastructure support servers (monitoring, autosys, DNS, Directory, etc)

  • Create a Linux infrastructure of shared servers behind the firewall

  • Create a Linux ‘goddard’ and a Linux ‘lindy’ for testing

Phase Three (June-Dec 2004): “get out the ladder”: harder to migrate, high risk



  • Shared application servers

  • Clusters

  • Databases

Phase Four (2005 and on): “plant a new tree”: long-term candidates



  • Applications that are not currently supported in Linux

  • Applications that would require an extensive development effort (Microsoft Windows IIS/ASP/VB)

Migration Methodology
Business Justification: determine the business logic for the migration. Does the migration make good business sense?
Platform Evaluation: do a cost comparison to determine whether it would be worthwhile to run the application under Linux. See TSS Migration Cost Comparison Guidelines.
Crash&Burn/Pilot: install the application on Linux to see if it really works and what it requires. The Pilot does not have to be integrated in our environment.
Test: if the pilot is successful, the next step would be to test the application in our Linux computing environment, integrating it with our infrastructure.
Pre-Production and User Acceptance Testing: the third step would be to install the application in a copy of our production environment. This step would test the functionality of the application, performance, and would include user acceptance testing.
Production

Download 20.07 Kb.

Share with your friends:




The database is protected by copyright ©ininet.org 2024
send message

    Main page