RISC_vs_CISC_Migration_from_UNIX_RISC_to_Intel_based_Solutions.pdf

7/27/2019 RISC_vs_CISC_Migration_from_UNIX_RISC_to_Intel_based_Solutions.pdf

1/16

Mirtin rm UNIX/RISC nMinrm t Int-s SutinsA Practical Migration Guide

introductionMany Fortune 500 corporations have successfully migrated legacy SPARC/

Solaris and Power/AIX infrastructure to Intel Xeon processor-based servers

running Linux.* Most have achieved signicant business and IT benets, including

better performance and reliability, lower capital and operating costs, and better

exibility and agility for future growth. They have also reduced the load on their

data center infrastructure. As youll see in the case studies referenced in this

paper, the benets can be substantial, even transformative.

Tis wit r is sin t tcnic cisin mkrs

unrstn t rquirmnts succssu mirtin. It ris

i-, st--st uiins s n mt tt s

n us succssu r mn rs n crss mn irnt

mirtin scnris.

Reading this guide from beginning to end will provide you with an overview

of migration requirements for various types of applications and workloads.

If you want to identify requirements for a specic migration:

1. Find your migration type in Table 1.

2. Read a brief summary of migration requirements for that particular type

of migration in the section entitled, The Migration Spectrumfrom Simple

to Complex.

3. Read the detailed description for each step in the sections that follow.

4. For additional tips, see the section: Using Tools to Simplify and

Accelerate Migration.

Was Peea

Senior Solutions Architect

Ga Hwa

Senior Solutions Architect

Sa Kha

Global Mission Critical Initiatives

To learn more about

modernizing your mission

critical environment, go to

www.intel.com/servermigration

WHitE PAPEr

riSc Mga

Mission-Critical Solutions


2/16

Wh Mgae

There are a number of reasons why

organizations choose to migrate away

from legacy UNIX/RISC infrastructure.

Many nd their existing hardware and

software environment is too costly to

maintain and support. The high costs

are often compounded by the lack of

exibility and agility, which can result

in additional costs due to lost business

opportunity and an inability to respond

to changing needs. Many of these organiza-

tions would like to move to a more exible

and affordable computing platform, but

are concerned about the cost and risk

of migration.

Although careful assessment is always

important to conrm viability, migration to

Intel architecture is most often a worth-

while process and tends to cost less than

upgrading existing UNIX/RISC environments.

Best practices have been rened over more

than a decade, services and support are

widely available, and most obstacles thatare likely to arise can be overcome by a

skilled team of business and IT specialists

working together.

Ongoing technical advances in industry-

standard servers and solutions have made

migration even more attractive in recent

years. Scalable servers based on the Intel

Xeon processor E7 family provide robust

support for mission-critical applications.

Eight-socket servers with up to 80 cores,

160 threads, and 4 terabytes of memory

are currently available and are well suited

to large, enterprise workloads. Even larger

systems are offered by select vendors.

This class of Intel Xeon processor-based

server also includes advanced reliabil-

ity, availability, and serviceability (RAS)

features integrated at the silicon and

system level to provide the data integrity

and system resilience needed in mission-

critical environments.1 Support for key

RAS features has been integrated into

many mission-critical solution components,

including the Linux operating system (OS)

and major databases.

The benets of migration can be compelling.

As evidenced by the case studies cited in

this paper, companies have saved millions

of dollars by migrating mission-critical

applications to Intel Xeon processor-based

servers running Linux. They have also

improved performance and availability and

eased the load on their existing data center

facilities. In some cases, space, power, and

cooling requirements have been reduced by

as much as 90 percent.2

Migration also improves the exibility of

IT environments. Intel Xeon processor-

based servers running Linux are supported

by one of the worlds largest vendor com-

munities. Businesses have more hardware,

software, and service options, and they

benet from faster innovation and more

competitive pricing models.

tabe ces

i 1

Wh Mgae 2

ce Mga isses 3

Code and Data Conversion. . . . . . . . . . 3

Limiting Outage during

the Switchover . . . . . . . . . . . . . . . . . . . .3

the Mga Spem

m Smpe cmpe 4

Infrastructure Applications . . . . . . . . .4

Remote Ofce/Retail

Computing Applications . . . . . . . . . . . .4

Mission-Critical Common-

Off-the-Shelf (COTS) Applications. . . 4

Mission-Critical

Custom Applications . . . . . . . . . . . . . . .5

Mga Mehg 6

Project Planning . . . . . . . . . . . . . . . . . . . 6

Code Conversion . . . . . . . . . . . . . . . . . . .8

Proof of Concept (PoC) . . . . . . . . . . . 10

Solution Architecture . . . . . . . . . . . . .12

Pilot Migration . . . . . . . . . . . . . . . . . . . .13

Rehearsal Migration . . . . . . . . . . . . . . 14

Production Migration . . . . . . . . . . . . . 14

usg ts Smp

a Aeeae Mgas 14

cs 15

EnvironMEnt

MEtHodoloGy StEPS

1 ProjEct

PlAnninG

2 codE

convErSion

3 Proof of

concEPt

4 Solution

ArcHitEcturE

5 Pilot

MiGrAtion

6 rEHEArSAl

MiGrAtion

7 Production

MiGrAtion

iase

Remote Ofce/Retail

cmpg

Mss-ca cotS

Appas

Mss-ca csm

Appas

tabe 1 Identifying the Appropriate Steps for Your Migration.

2

Mgag m unix/RISC to Linux* on Intel Architecture


3/16

Many companies have taken advantage

of virtualization during or followingtheir migration, not only to simplify and

consolidate their infrastructure, but also

to improve scalability, availability, and

control. IT organizations are increasingly

comfortable virtualizing mission-critical

environments. It lets them utilize physical

resources more efciently and add virtual

resources during workload spikes to

maintain service levels. Virtualization

can be used to complement other high

availability technologies to enable more

comprehensive high availability anddisaster recovery solutions. It also lays

a foundation for layering on advanced

cloud functionality, so businesses are

better positioned to take advantage of

next-generation computing models if

and when they choose.

ce Mga isses

Careful planning is essential to identify

and mitigate the risks that exist in

any migration project, and to ensure

that business and IT goals are met.

For businesses undertaking their rst

migration, it is generally best to include

experienced consultants as part of the

team, preferably from a vendor that has

conducted similar migrations. Consultants

will understand common challenges and

solutions, which can simplify planning

and reduce risk. Active participation by

internal business and IT personnel is also

crucial, since they will understand the

companys unique challenges and require-

ments, such as success factors, service

level agreements (SLAs), enterpriseprocedures, and political issues.

Although migration is a detailed process

with many issues to consider, two coreissues arise in most migrations. The rst

is code and data conversion. The second is

limiting the application outage during the

switch-over to the new solution.

ce a daa ces

In very simple migrations, there

may be no need for code conversion.

However, whenever custom applications,

shell scripts, or data are migrated,

varying degrees of code conversion

will be required.

Linux is quite similar to UNIX, but there

are syntax and directory differences that

must be addressed. Tools exist that can

automate much of the process, but the

results need to be tested and optimized

as the code is reiteratively compiled to

ensure SLAs are met. If the code is modern,

well written, and well documented, conver-

sion should be straightforward and time

and effort will be roughly proportional to

the size and complexity of the code base.

If the code is old and poorly documented,conversion may be more challenging. A

careful assessment should be conducted

prior to migration, so time and resources

can be allocated accordingly.

One signicant code difference between

RISC and Intel architectures is referred

to as endianess. RISC and mainframe

architectures (Sun SPARC,* IBM PowerPC,*

IBM z-series,* etc.) are big endian, which

means the most signicant bits of a multi-

byte number are stored in the memory

location with the lowest address. Intelarchitecture is little endian, so the most

signicant bits are stored in the memory

location with the highest address. Sincethis is a consistent difference between

the two architectures, it is straightfor-

ward to convert data when it is trans-

ferred across the network between

one platform and the other.

lmg oage dg he Swhe

In an ideal migration, it would be possible

to have the new solution up and running

before the old one is turned off. However,

most applications take in data continuously

and all data must be present in the new

solution at the instant it goes live. This

typically requires shutting down the

old application, transferring data, then

turning on the new application. Minimizing

downtime and risk for this switchover is a

primary focus of most migrations.

The majority of database migration tools

address this issue, and, with proper plan-

ning, the shutdown can typically be limited

to seconds or minutes. For applications

with extreme uptime requirements, it may

even be possible to eliminate downtimealtogether, but this requires specialized

tools and expertise. As one example,

Oracle GoldenGate* (discussed later

in this paper) enables data migration

without downtime for many Oracle

Database solutions.

3

Mgratg from Unix/RiSC to Lu* o itel Archtecture

3


4/16

the Mga Spem

fm Smpe cmpeMigrations from UNIX/RISC architectures

vary in complexity and entail varying

degrees of cost and risk. The following

categories are arranged from the simplest

to the more complex and account for the

majority of data center migration types.

iase Appas

Examples: DNS, LDAP, web servers, rewalls,

backup and restore, le and print.

Migrating infrastructure applications can

be simple, even trivial. In most cases, the

application will be available in versions

that run natively on both architectures

and little or no code conversion will be

required. Switchover to the new solution

also tends to be relatively easy, sincedowntime windows are not a signicant

concern. Once the initial migration is per-

formed, it can be replicated across other

instances of the application throughout

the enterprise, resulting in exceptionally

high value with low cost and risk.

Remote Office/Retail

cmpg AppasExamples: Business applications running at

multiple locations, such as remote ofces,

bank branches, retail stores, etc.

One of the primary challenges of applica-

tion migration is that every migration

tends to be different, requiring business

and IT personnel to reexamine goals,

requirements, and processes.

However, when a business runs the same

application in multiple locations, such

as remote ofces and retail outlets, the

cost and risk of migration are defrayed

across all application instances. As with

infrastructure applications, the team can

perform one pilot migration, optimize the

implementation process, and then repli-

cate the migration across all locations.

Cost and risk will be variable for

the pilot migration depending on

the complexity of the solution stack.

However, as long as the same software

stack is used across locations, all remaining

migrations should be simple and relatively

risk-free, which greatly increases the total

value of migration.

Mss-ca cmmea-

o-he-She (cotS) AppasExamples: Re-hosting core businessapplications, such as SAP, Oracle eBusiness

Suite,* and associated databases

In addition to hardware and OS migrations,

mission-critical COTS applications can be

migrated at the database layer, the appli-

cation layer, or the web services layer. In

some scenarios, all three layers are hosted

in partitions on a large UNIX/RISC server.

In many others, the Web or application

layers are already hosted on Intel Xeon

processor-based servers. If more than one

layer is being migrated, it is generally bestto perform the migration in stages. This

reduces risk by decreasing the number

of simultaneous variables, making it easier

to identify and resolve any issues that

arise during migration.

Migrating mission-critical applications also

introduces the two core issues discussed

earlier: converting code and minimizing

application downtime during the migra-

tion. If the application runs natively on

Intel architecture, the challenges of code

conversion are greatly reduced. However,it may still be necessary to convert shell

scripts and other custom-coded elements.

Project Planning

Pilot Migration

Production Migration

1

2

3

rEquirEd StEPS

rEquirEd StEPS

Project Planning

Code Conversion

Solution Architecture

Pilot Migration

Rehearsal Migration


1

2

3

4

5

6

2

3

rEquirEd StEPS rEquirEd StEPS

Project Planning

Code Conversion


Pilot Migration

Rehearsal Migration


1

2

3

4

5

6

2

3

rEquirEd StEPS

4



5/16

In general, the workow for a mission-

critical migration involves performing adetailed assessment, followed by any

required code conversion and a proof-of-

concept (PoC) to demonstrate the feasibility

of migration. Assuming a successful PoC,

the migration team will then architect the

solution for scalability and high availability,

size the new solution for production work-

loads and perform one or more migration

rehearsals to optimize migration processes.

The rehearsals are essential to ensure

the switchover in the nal production

migration can be performed quicklyand with minimal risk.

The same basic methodology applies

to multiple scenarios of varying

complexity, including:

re-hsg a appa sak wh

swae hages Migration should

be relatively simple and straightforward,

since only data unique to the enterprise

must be transferred.

re-hsg a appa sak wh

swae es hages (e.g., Oracle9i* to Oracle 11g*). Version changes add

complexity, since additional variables

come into play. For example, migration

tools on the newer version may not

be available on the older version. It

might also be necessary to convert

application code to run successfully

in the new application version.

Engaging with the software vendor

or an experienced migration consultant is

recommended to ensure that application

changes and dependencies are

well understood.

re-hsg appa saks

ha ee sga pgaes(e.g., changing the software application

or the underlying database). Software

stack upgrades introduce multiple simul-

taneous changes that can make it hard

to identify the source of any issues that

arise. The migration should be broken

into discrete steps if possible. For exam-

ple, first migrate the existing application

tier and then migrate the database.

Mss-ca csm Appas

Examples: An application written to support

unique processes for a single business (often

in C++, C, or Java)

Migrating custom applications introduces

the additional challenge of large-scale

code conversion. Initial assessments

should take into account the availability

of source code, porting tools, libraries,

documentation, and knowledgeable

developers, since all these factors can

have a signicant impact on cost, risk,

and timelines.

The time and effort required for code

conversion will be roughly proportional tothe size of the code base. Major OEMs and

Linux vendors have mature tools that can

be used to automate much of the process,

especially for porting code from UNIX/

RISC environments. The tools read the

source code and identify required library

and syntax changes. Some manual coding

will also be required, followed by careful

testing and optimization to ensure func-

tionality, stability, and performance. Oncecode conversion is complete, the migration

team can follow the processes outlined

for mission-critical vendor applications.

Migrating mainframe applications tends

to be more complex, but not always. For

example, migrating a vendor application,

such as SAP, or a vendor database, such

as Oracle Database or IBM DB2, can be

relatively simple. Migrating custom appli-

cations tends to be more challenging, but

can be straightforward if the code is mod-

ern, well written, and well documented.Migrating older custom applications can be

quite challenging. A 30-year-old main-

frame application may have been modied

and patched many times, and the code is

likely to be monolithic, brittle, and poorly

documented. The original developers may

be long retired, and it may be hard to nd

new developers that understand the lan-

guage, whether its COBOL, PL/1, another

mainframe language, or JCL. The applica-

tions running on a mainframe may also

be interdependent, making it necessaryto migrate multiple applications and data

sets at the same time.

These issues are beyond the scope of

this paper. However, companies have

been migrating mainframe applications

to Intel architecture for many years, and

experienced vendors are available with

expertise and toolsets that can reduce

cost, effort, and risk. For a detailed exam-

ple of mainframe migration methodology,

see Re-Hosting Mainframe Applications

on Intel Xeon Processor-based Servers at:wwweaaeemgam

rEquirEd StEPS

Project Planning

Code Conversion

Proof of Concept


Rehearsal Migration


1

2

3

4

5

6

2

3

rEquirEd StEPS

5



6/16

Mga Mehg

Every migration is different. The follow-

ing methodology provides a good starting

point for most migrations, but will need

to be adapted to address specic require -

ments. The methodology is broken into

discrete steps and not every step will be

necessary in every migration (see

Table 1, at the beginning of this paper,

for recommendations).

Pe Pag

Careful planning lays the foundation for a

successful migration. The following stepsare recommended.

1 uesa gas There are

many reasons for migrating a large,

legacy RISC server to Intel architec-

ture, including strategic or tactical

business needs, the need to refresh

aging infrastructure, cost reduction,

performance, energy efficiency, reli-

ability, space reduction, and the desire

to standardize or virtualize infrastruc-

ture. Understanding and documenting

the relative importance of these andother goals provides a framework for

decision making throughout the

planning process.

2 dee he spe Identify the applica-

tions, servers, storage, data centers, and

other components that will be included

in your migration. Keep it as simple as

possible, since the broader the scope,

the greater the complexity.

3 dee sess ea To the

extent possible, your criteria should

be quantitative, such as reducing total

cost of ownership (TCO) by a particular

percentage or handling a certain num-

ber of transactions per second within a

specified average time. Include all key

criteria that are important to success.

4 Smae tco a re

iesme (roi) Applications areavailable to automate this function,

either off the shelf or from many ser-

vice providers. In conjunction with your

documented goals, scope, and success

criteria, these assessments provide

you with the information you need to

gain buy-in from project stakeholders,

which can be critical in any major

migration project.

5 Assess y Esg Eme

In this step, you perform a detailed as-

sessment of your existing environmentto determine migration requirements

and identify potential risks. Take a

balanced approach. It is important to

analyze your situation carefully to

ensure no major requirements or risks

are overlooked. However, over-analysis

is a risk factor that can drive up costs

and create inertia. The following pro-

vides a recommended approach for a

balanced assessment.

Review and explore your existing

solution documentation, application

options, and hardware options from

your preferred vendor (see the side-

bar on page 11, Choosing the Right

Intel Xeon Processor-Based Servers).

Is your application available in a native

version for Intel architecture? Is it the

same version level as your existing ap-

plication? If not, what impact will these

differences have on your solution,

your users, and your migration?

MIgRaTIoN IN The Real WoRld:

ely lIlly

repamg he

Eepse Bakbe

The worlds 10th largest pharmaceutical

company has completed about 70

percent of an enterprise-wide transfor-

mation aimed at replacing all UNIX/RISC

platforms with Linux* running on Intel

architecture. The ultimate test came

with the migration of a global SAPdeployment supporting 50,000 users.

The project was a success, resulting in:

Multi-million-dollar savings with

expected payback in two years

A 90 percent reduction in the data

center footprint with 80 percent

lower power consumption

An average performance improvement

of 11 percent, even though much

of the code was optimized for the

previous infrastructure

Read the full case study at:

http://support.intel.co.jp/content/

dam/doc/case-study/mission-critical-

mpg-e-7500-5600-e--

ase-sp

6



7/16

Compile an equipment and application

inventory of your existing environ-ment. If no credible inventory exists,

you can perform this manually or

you can license software that auto-

matically discovers assets. Discovery

software tends to be faster and can

assist with documenting application

dependencies, but is rarely perfect.

Some degree of manual discovery will

be required. There may be existing

hardware and software components

you wish to continue using in your

new environment. You will need todetermine whether they are com-

patible, and, if not, whether suitable

alternatives are available.

Create a profi le of the application

you wish to migrate. You will need

to understand what the application

is being used for, how it operates,

and who uses it. You will also need

to understand data sources and data

flow, and identify all application de-

pendencies and external linkages.

Dependencies can be as simple as ahard-coded host name or as complex

as inter-process communications. One

example of a common dependency is a

limitation on the supporting operating

system versions. If you are migrat-

ing a custom application, evaluate the

size and complexity of the code. Do

you have access to the source code,

documentation, vendor libraries, and

developer resources?

Evaluate the data that will need to be

migrated. Will you be using the same

or a new database application? Is the

data in binary format?

Document critical solution require-

ments for storage, servers (CPU,memory, and I/O), the network, and

SLAs. Consider backup and disas-

ter recovery solutions, as well as the

production environment. Assessing

CPU requirements can be tricky when

moving to a new architecture. For

guidance, see step 8, Preliminary

Server Sizing.

Assess the security environment

of the existing solution. The goal

here is to understand how security is

implemented so you can re-implementa similar solution or architect a new

one. In general, it is also advisable

to review any documented information

security policy updates for the appli-

cation or for the company as a whole.

You dont want to re-implement an

existing security solution only to

find out it is no longer adequate to

address requirements.

Assess infrastructure and operations

for the existing solution, including

people, processes, and tools. If yournew solution will be designed to

fit into the existing environment,

what changes might be required?

Alternatively, does the migration

provide an opportunity to improve

infrastructure and operations to

provide a more efficient IT framework

for the new computing platform?

6 deeme easb a e

sks Based on all the informationyou have collected, assess the fea-

sibility of your migration and identify

potential risks. Is it feasible from a

technical standpoint? Can you meet

requirements for performance, scal-

ability, availability, security, and data

integrity? Do you have the necessary

experience, skills and resources avail-

able to conduct the migration or will

you need assistance or guidance from

outside vendors? Can you integrate

the new solution efficiently into youroperational environment? Can you

be sure of stakeholder support and

the funding you need to complete

the project?

7 dee whehe pee

Revisit your TCO and ROI analyses to

be sure they remain on track. Weigh

the expected gains against the risks

associated with the project to de-

termine whether it makes sense to

proceed with the particular migration.

7



8/16

8 Pema See Szg If you

decide to proceed, you will need toassess the load on your current server

in detail, so you can determine an

appropriate configuration for proof-

of-concept (PoC)3 testing. A common

mistake in many migrations is to invest

a lot of effort to determine a precise

configuration for the production hard-

ware before the application has been

tested on the new system architec-

ture. Application performance can

differ dramatically in going from one

architecture to another, and only per-formance testing on similar platforms

can provide accurate performance esti-

mates. At this stage, you only need a

reasonable preliminary estimate to

support your test requirements. Your

pilot migration or PoC will ultimately

provide the detailed information you

need to size your production server.

Determining memory and disk space

for your test server is fairly straight-

forward, since the requirements will be

very similar to your legacy infrastruc-ture. Determining CPU requirements,

however, is not so simple. There are

both architectural and generational

differences to consider, including the

numbers of cores, threads, cache, in-

structions per clock cycle, and many

other factors. One way to approach

this task is to use performance moni-

toring tools that are available in most

UNIX operating systems. If not, you

can add the Sysstat4 package of tools

to measure key performance statistics

and identify bottlenecks.

vmstat collects statistics pertaining to

operating system memory, processes,

interrupts, paging, and block I/O.

iostat collects operating system

storage input and output statistics.

netstat displays network connections,

routing tables, and a number of net-work interface statistics.

mpstat collects processor related

statistics to monitor CPU usage.

System Activity Reporter (sar)

normally collects performance data

every 20 seconds, but can be config-

ured to monitor performance metrics

over longer intervals.

Use these tools to collect data through

a normal business cycle. This is typi-

cally a month, but can be as long as aquarter. Identify peak requirements and

combine this performance information

with benchmark data (from TPC.org or

SPEC.org) for your legacy platform and

your target Intel Xeon processor-based

server. With this information, you can

roughly estimate CPU requirements for

your PoC tests.

Alternatively, you can use a sizing tool

to assist with your estimations. You

will need to purchase an appropriate

sizing tool, some of which require theinstallation of performance measuring

agents in your legacy server. After col-

lecting data for your specified period,

the sizing tool will analyze the data

and recommend an appropriate Intel

Xeon processor-based server.

ce ces

Code conversion is necessary whenever

the application is not available in a version

that runs natively on Intel processors.

It is also required for shell scripts and

other custom code components. Code

conversion can be relatively simple or

very complex, depending on the quality

and availability of source code, documen-

tation, porting tools, and developers with

appropriate skills and experience. For

large and complex custom applications,

consider writing a new application from

scratch or moving to an appropriatevendor or open source application.

The emergence and adoption of standards

such as POSIX.1, UNIX 95, and UNIX 98 has

signicantly reduced the complexity of

code conversion by fueling a convergence

in application programming interfaces

(APIs). However, even in standards-based

code, some discrepancies are likely to be

found due to ambiguities in the standard

or issues that are covered imprecisely by

a conformance suite and are implemented

in different ways on the two platforms.These kinds of issues create complexi-

ties that must be dealt with in most code

conversion efforts.

In general, the more compliant the applica-

tion source code is with language, coding,

and run-time standards, the easier it will

be to port to the new computing plat-

form. Source code that conforms to the

standards listed above and to the relevant

ANSI/ISO standard will be easy to port, as

will source code that is already portable to

multiple platforms. Source code changes

will be required if the source code:

Includes assembly source modules or

inline assembler statements.

Exploits specific knowledge of the

UNIX/RISC platform you are replacing

(for example, hard-coded assumptions

about page size or knowledge of the

OS, such as file system layout).

Depends on endian-specific data.

Calls proprietary APIs or exploits

undocumented features of the OS.

Is linked and runs in kernel mode.

This includes kernel modules and

device drivers.

8



9/16

In general, the recommended process

for code conversion is as follows.5

1. Gather source code and

conversion tools.

2. Plan source code conversion tasks.

If the project seems out of scope

based on in-house expertise and

available resources, consider

outsourcing the conversion.

3. Determine if your hardware or

software vendor provides tools to

assist in code conversion. Several key

original equipment manufacturers(OEMs) provide mapping papers

or tools to help determine the obvious

changes, such as directory structures

for the include files and recommended

syntax changes for shell scripts and

other control programs.

4. Identify your applications development

environment dependencies, includ-

ing the tools used for source code

management, the build environment,

installation, application management,

development, profiling and performance

measurement, testing, and documenta-

tion. Include third-party products, such

as libraries, applications servers, and

application completers.

5. Identify and assess the likely impact

of differences in the operating sys-

tems, cluster features, run-time

libraries, and third-party product

versions that might affect your

code conversion project.

6. Identify and plan for any end-userimpact that might result from deliver-

ing your application on the new target

system. This can include the need for

data conversion, uptime support during

the transition period, product installa-

tion changes, product administration

changes, and training.

7. Identify and address the application

porting teams need for documentation

and training.

8. Port your application development

environment and adapt your develop-ment procedures as needed.

9. Clean up the application source code,

identifying and removing architectural

dependencies and nonstandard prac-

tices where possible.

10. Extend the application source code

to support the new target platform.

This can include the addition of con-

ditional modules and conditional code

(both high-level and assembler code).

Generalize implementations to avoidarchitectural dependencies if possible.

11. Compile the source code, preferably

using ANSI or more strict error

checking switches to flag potential

issues. Fix any problems found at

compile time.

12. Run the application with a broad set

of test cases, debug any problems,

and correct any run-time problems

that are detected.

13. Repeat steps 11 and 12 as necessary.

When planning your code conversion

project, it is important to evaluate cus-

tomer support requirements for the new

application, which may increase during the

transition period. For example, if you add

or modify customer-initiated procedures

or change remote diagnostics tools and

techniques, documentation and training

may be required for customers and support

staff. Other issues to consider during plan-

ning include acceptance testing, the need

for additional system backups during thetransition, and the impact of the application

changes on any archives that are required

for business or legal reasons. For applica-

tions that are particularly critical to the

business, you may also want to consider

the need for parallel operation of both

application versions during the transition.

MIgRaTIoN IN The Real WoRld:CalIfoRNIa depaRTMeNT of

WaTeR ReSoURCeS (CdWR)

Bg a f Eme

With a heterogeneous and aging IT

infrastructure, CDWR was hard

pressed to avoid outages and con-

tain rising costs. By virtualizing and

consolidating the entire infrastructure,

including mission-critical enterprise

applications, on Intel Xeon processor-based servers, CDWR achieved:

Up to 4x better ERP performance

4x higher capacity, while reducing

the server footprint by 65 percent,

power consumption by 40 percent,

and cooling by 50 percent

A 25 percent reduction in operating

expenses, including USD 2.2 million

savings in maintenance costs

70 percent faster IT provisioning to

support growth and change

Read full case study at:

http://www.intel.com/content/

www/us/en/virtualization/

aza-e-5600-aa-

epame--wae-eses-

shm

9



10/16

P cep (Pc)

All complex or mission-critical migrationsshould include a PoC to:

Verify the application can run in

the new environment

Determine how it performs

Optimize configurations to

maximize performance

Determine preliminary processes

for the production migration

Recommended steps for a PoC

are as follows.

1. Size and acquire an appropriate server

for the PoC. (See Project Planning,

step 8, earlier in this paper.) Sizing

need only be approximate at this time.

Performance measurements during

the PoC will be used to determine a

best-fit production configuration.

2. Size and acquire an appropriate storage

solution for the application. For smaller

applications, this can be high capac-

ity, solid state drives in a PCIe slot. For

larger applications, it can be hard disksor solid state drives in a storage area

network (SAN) or network attached

storage (NAS) array.

3. Determine an appropriate OS

configuration for the PoC, including

release levels and patch levels.

4. Determine the application

software configuration.

5. Identify your user acceptance testing

(UAT) processes and resources. This

can be a regression test harness ora group of users to bang on the sys-

tem. If you use a test harness, be sure

you have access to ancillary hardware

to simulate users.

6. Make sure you have appropriate

staffing for the PoC. You shouldhave full-time access to at least one

employee who is familiar with the

application and operating system

configurations and at least one

employee who is familiar with quality

assurance (QA) and UAT procedures.

This is important to avoid delays

during your PoC.

7. Configure your server for the PoC

and tune the OS for the application.

8. Document all current and requiredconfigurations, including versions

and patch levels, source code and

documentation, library issues,

application tuning parameters,

network links, and storage

configurations (paths and links).

9. Backup the application server before

you begin testing. It will be easier to

restore the initial configuration after

each test than to re-install and recon-

figure the application.

10. Connect the server to your dev-test

or lab subnet.

11. Use your test harness to measure

performance and identify bottlenecks.

Be aware that performance may be poor

initially and the bottlenecks you find

may be very different than those you

observed on the legacy platform. This

is to be expected since the source and

target architectures are quite different.


NCh CoRpoRaTIoN

Aeeag ErP

NCH needed to refresh the aging

infrastructure supporting its Oracle

enterprise resource planning (ERP)

environment. By replacing a large

number of RISC-based servers with

Intel Xeon processor-based system,

the company achieved:

Technology refresh savings of USD

5.5 million

More than 300 percent faster perfor-

mance for Oracle transactions

Improved productivity, reducing the

time for a currency rebalance from

four and a half hours to one hour and

ten minutes

Read the full case study at: http://

www.intel.com/content/www/us/

en/processors/xeon/risc-migration-e-7540-h-pa-s-

sags-shm

10



11/16

Optimizing performance is a standard

part of the PoC and can entail a sig-nificant amount of time so build this

into your schedule. Reiterative adjust-

ments of the application environment

might even include re-architecting the

platform for the PoC. This is where the

correct configuration (memory, CPU,

storage, etc.) for the production envi-

ronment will be determined.

The test harness can be a commercially

available performance testing tool,

such as Load Runner (www8.hp.com/

us/en/software/software-product.html?compURI=tcm:245-935779).

Such tools usually require an

elaborate configuration of hardware

that simulates the actual application

architecture. Alternatively, you might

hook this PoC test bed into the

regression testing harness used for

application development life cycle

testing. You could also use the more

mature Quality Assurance (QA) testing

platform or the User Acceptance

Testing (UAT) platform.12. Evaluate the cause of any

performance issues.

Monitor performance using tools

residing in the Linux OS, such as

vmstat, iostat, netstat, mpstat, or

SAR (described earlier in this paper).

Look for waits in the database,

such as delays in writing to log files or

anything affecting logging processes.

Look closely at memory size and

speed, the number of CPUs, networklinks, and the storage configuration.

When migrating mission-critical enterprise workloads, such as large databases, core

transactional applications, and business intelligence solutions, consider servers based

on the Intel Xeon processor E7 family. These servers provide a particularly

scalable and robust foundation for demanding applications. Each processor provides

up to 10 cores, 20 threads, and 30 MB of last level cache. An eight-socket server can

be congured with up to four terabytes of memory.

The Intel Xeon processor E7 product family includes advanced RAS features to

improve data integrity and system resilience. A key example is Machine Check

Architecture-Recovery, which enables automated system recovery from many

uncorrectable errors. Most server vendors offer a range of system-level RAS features,

such as redundant and hot plug components and built-in management modules.

Intel Xeon processors also include built-in Intel security technologies that provide

enhanced protection for systems, application, and data.

Intel Advanced Encryption Standards-New Instructions (Intel AES-NI)

accelerates encryption for any application that employs AES, a widely supported

encryption specication. By providing hardware support for encryption, it allows

IT organizations to implement stronger data protection without slowing downapplication performance or overloading servers.

Intel Trusted Execution Technology (Intel TXT) enables IT organizations to

establish pools of trusted infrastructure, by ensuring that servers and virtual

machines launch only into known good states. Instead of trying to counter

constantly changing attacks one by one, Intel TXT ensures that rmware and

software have not been tampered with prior to or during launch.

ChooSINg The RIghT INTel XeoN pRoCeSSoR-baSed SeRveRS

Intel Xeon processor-based servers are widely available in two-, four-, andeight-socket congurations that will meet the vast majority of requirements.

Larger systems are available from select vendors.

11



12/16

Analyze the data to determine the

source of the bottlenecks. Is thehardware inadequate? Does the OS

or underlying software need tuning?

If the application is custom-coded,

does the application architecture or

code need adjusting?

Make adjustments to optimize

performance, then retest and

re-optimize as needed.

13. Use your test data to determine the

proper configuration for the produc-

tion solution, then reevaluate your

ROI estimates accordingly.

14. Carefully document processes,

configurations, and results.

Note that some steps, such as porting

data, will need to be repeated during

subsequent phases of the migration.

Those processes should be

fully documented.

Others steps, such as rewriting shell

scripts or editing C++ code, will not

need to be repeated. Detailed, step-

by-step documentation for those

processes may not be necessary.

Still other steps, such as setting

environmental parameters for the ap-

plication, lie somewhere in between.

The processes for setting those pa-

rameters will have to be repeated. The

processes for determining the correct

settings will not. Adjust your documen-

tation accordingly.

15. Review the PoC and documentation

with the PoC team.

S Ahee

Once you have nished your PoC, youneed to step back and consider broader

issues, the most important of which are

ensuring the scalability and availability

of the solution. You have already deter-

mined that the application runs on the

hardware and are condent that SLAs

can be met, but there are several addi -

tional issues to consider.

rbs hawae With most migrations,

you automatically gain performance, scal-

ability, and RAS when you replace older

equipment with more robust, newer hard-

ware. You can add to these advantages by

configuring new systems with redundant

components, such as power supplies, disk

drives and fans. Be aware that the Intel

Xeon processor E7 family is designed spe-

cifically for mission-critical environments

and provides advanced support for data

integrity and system resilience at the sili-

con level. Servers based on this processor

family tend to provide more robust support

for mission-critical environments.

cseg You can also reduce the

effects of failure on your migrated

environment by using high availability

clustering software, which is available

as an option in leading Linux distribu-

tions. A redundant server is deployed

to take over the duties of the main

server in the event of a failure. While

failover is not instantaneous, it is

automatic. Clustering software limits

the effects of failure on overall

system availability.

Hza sag In a horizontally

scaled architecture, increasing workloads

are handled by adding additional servers,

rather than increasing the size of indi-

vidual servers. This can be an excellent

approach for presentation layer services,

which tend to scale well across multiple

servers through workload balancing. If


UNIveRSITy of ColoRado

lage Sae daa

cee csa

To address rising costs, the University

of Colorado migrated its mission-

critical IT environment from RISC-

based servers to Intel Xeon

processor-based systems. The

results were transformative.

The data center footprint wasreduced by 95 percent and power

consumption by 90 percent

USD 600,000 was saved from the

total IT budget in just the first year

after migration

Performance for the Oracle ERP

application was improved by

400 to 600 percent

Read the full case study at:

http://www.cisco.com/en/US/

solutions/collateral/ns340/ns517/ns224/U_of_Colorado_casestudy

_nal.pdf

12



13/16

a server fails, its workload automati-

cally fails over to the remaining servers,providing high availability as well as scal-

ability. Two-socket servers based on the

Intel Xeon processor E7 family support

larger memory footprints and include

robust support for high availability and

data integrity. Automated provisioning

and maintenance tools are recommended

to keep management overhead low as

the solution expands.

vea Sag In a vertically scaled

architecture, the application resides on a

single server. As workloads grow, perfor-mance is scaled by adding resources to

the server or upgrading to a larger sys-

tem. Applications that are appropriate

for vertical scaling tend to be mature or

single-purpose applications that exhibit

a high degree of scalability, such as data-

bases and transactional applications.

Here again, servers based on the Intel

Xeon processor E7 family tend to be

the best choice. They provide the higher

levels of reliability and availability needed

in a vertically scaled solution. They alsoprovide more CPU resources (cores,

cache, and bandwidth), and come in

larger server configurations to support

heavier workloads.

P Mga

A pilot migration is appropriate whenever

an application will be deployed across

multiple locations. For an application to

be a good candidate for a pilot migration

(rather than a more extensive PoC):

The application must be available in anoff-the-shelf version that runs natively

on Intel architecture.

Application functionality and interfaces

must be standard across instances.

A reasonable amount of application

downtime must be acceptable, soextensive testing and rehearsals

are not required to optimize the

switchover process.

The following steps are appropriate

for most pilot migrations:

1. Acquire and configure the Intel Xeon

processor-based platform for the pilot.

(See Preliminary Server Sizing earlier

in this paper for details.)

2. Install the application.

3. Use a test harness to validate function-

ality and performance in a simulated

production environment.

4. Make changes as needed to ensure

the new solution will meet SLAs.

5. Based on the results, determine a

best-fit server configuration for the

production environment and verify

that the new solution will meet return

on investment (ROI) criteria.

6. Acquire the new server, load theapplication, run your test, and deploy

the new server into production.

7. Document the solution configuration

and setup procedures.

8. Replicate the solution across the

infrastructure. This step is frequently

executed by a team from a system

integrator with a national or even

international reach. It can also be

executed by an internal team tasked

with traveling to each site that

requires the upgrade.

MIgRaTIoN IN The Real WoRld:hSbC

re-Hsg Me

Maame Appas

HSBC encountered performance

and reliability issues for a key main-

frame after deploying a new suite

of loan applications. Migrating

the applications to Intel Xeon

processor-based servers delivered:

A better experience for customersand branch office personnel due

to improved performance and

higher uptime

Lower costs and greater headroom

with 70 percent lower monthly

service charges and a 2,000 MIPS

reduction in mainframe workloads

Improved business flexibility with an

infrastructure that is easier to scale

and adapt

Read the full case study for more infor-mation about the HSBC methodology

and migration experience.

wwweaaeemgam

13



14/16

reheasa Mga

Ensuring a successful switchover to thenew solution requires careful preparation.

Your PoC migration steps were not opti-

mized for simplicity, speed, or efciency.

Tasks were accomplished iteratively

(testing, optimizing, and retesting)

and not in a straightforward sequence

appropriate for the production migration.

A rehearsal is needed to optimize and

validate the migration process.

Your documentation from the PoC

provides a recipe for the rehearsal. The

goal is to rene the steps of the PoC to

streamline the production migration and

ensure a seamless transition that mini-

mizes any downtime. The following steps

can be used to prepare and conduct your

rehearsal migration.

1. Streamline your documented PoC

migration process by determining

which steps are necessary and reor-

dering them as appropriate to optimize

efficiency. Note which steps can be

performed in parallel and which can be

performed before shutting down the

production system for the switchover.

Your goal is to accomplish as much as

possible before switching off the pro-

duction system in order to minimize

downtime during the migration.

2. Once you have determined the steps

of your production migration, develop

scripts to automate every process that

can be automated.

3. Perform the rehearsal starting with a

clean slate. Recreate the pre-migrationsteps, then execute all data migration

steps as rapidly as possible, since they

represent the key cause of downtime

during the transition.

4. Document all your steps, including

any additional refinements and thetime required to perform each step.

5. Test the solution for QA

and acceptance.

6. Repeat the rehearsal migration as

needed until you are confident you

can perform the production migration

quickly and without incident.

P Mga

By the time you reach this point, you

should have full condence in your new

solution and your migration process.

1. Use your documentation from the

rehearsal to develop a tight project

plan for the migration.

2. Schedule an optimal maintenance

window and notify all affected

business units.

3. Rebuild the target server and finalize

all pre-migration steps.

4. Execute the production migration

as rehearsed.

5. Run the system through your QA and

acceptance procedures.

6. Cut over or run in parallel depending

on requirements.

7. Document everything that was done.

usg ts Smp

a Aeeae MgasA broad range of tools are available

to help with migrations, including capac-

ity planning tools for server sizing, code

conversion tools, and database migration

tools. If this is your rst migration from

a UNIX/RISC platform to Linux on Intel

architecture it is probably best to work

with an experienced vendor to determine

best-t tools and processes for your spe-

cic migration. Many server, OS, and appli-

cation vendors have extensive experience

helping customers with migration projects.There are also many service providers

who specialize in code conversion and

platform migration.

The right tools can provide signicant

advantages. In a database migration, for

example, the choice of data migration

tools can make a difference between

several hours of downtime and no

downtime at all. Organizations must

also consider the cost and complexity of

using particular tools and processes. The

following example describes three differ-ent tools that can be used to migrate an

Oracle database to Intel Xeon processor-

based servers. Multiple options are avail-

able for other leading databases, as well.

These and other tools should be evaluated

carefully prior to use to ensure alignment

with specic goals and requirements.

14



15/16

Option 1: Oracle export/import utility.

This is the simplest method for migratingan Oracle database from a legacy platform

to an Intel Xeon processor-based server.

It uses tools that are familiar to database

administrators and are resident in Oracle

Database. The process is straightforward.

1. Configure the new Intel Xeon proces-

sor-based server.

2. Run a script to set up your database

structures (tables and packages).

3. Move any static (read-only) data

before application shutdown.

4. Shutdown the production application

and use the export/import utility to

transfer your data.

5. Move active data in parallel export/

import streams.

6. Create indexes using parallel processing.

7. Run referential integrity constraints

after the data is imported.

8. Restart the production database on

the new server and run your tests.

9. Release the new solution to production.

op 2: oae Seams

This process is more complex, but the

production application can remain running

through most of the migration. Oracle

Streams is available as a utility of the

Enterprise Edition of Oracle Database.

1. Configure the Intel Xeon processor-

based target server and a thirdintermediate database server with

operating systems, then install the

Oracle database. The architecture of

the third server should be the same

as the production server (i.e., another

RISC server). However, it could be a

virtual server and does not have to be

as robust as the production system,

since it will only be used for shipping

the redo logs.

2. Backup the production database and

Convert DB using Oracle RMAN.

3. Restore the production environment

on the target server.

4. Ship the transaction logs to the third

intermediate database up to SCN.

5. Shut down the production database

and apply the last database changes

to the target server.

6. Clean up.

7. Shut down the production database.

8. Restart production on the new

database server and run your tests.

9. Release the new solution to production.

Option 3: Oracle GoldenGate.*

This option requires little or no application

outage. GoldenGate is sold separately

from Oracle Enterprise Edition database,

and there may be limits and restrictions.

It is important to consult with Oracle

to understand migration steps, limits,

and restrictions.

cs

Intel Xeon processor-based servers

running Linux have proven their ability

to handle the mission-critical workloads

that used to be the purview of UNIX/

RISC and mainframe architectures.

Migration can help IT organizations

reduce costs, improve service levels,

and provide a better foundation for

growth and innovation. It can also help

them establish an open, standards-based

foundation for moving progressively

toward 100 percent virtualization and,

ultimately, cloud computing.

A successful migration requires a careful,

methodical approach based on best

practices, as described in this paper. Many

additional resources are available from

Intel, from leading server, OS, and applica-

tion vendors, from the open source Linux

community, and from service providers

around the world. Successful migrations

have been performed for several decades

now, and vendors with extensive migration

experience are widely available.

15



16/16

For more information and resources, visithttp://www.intel.com/content/www/us/en/mission-critical/mission-critical-meeting-todays-it-challenges.html

For more resources and tools visit our web site devoted to this topic atwwweaaeemgam


1 For detailed descriptions of the RAS features provided in the Intel Xeon processor 7500 ser ies, see the Ideas International white paper, Red Hat Enterprise Linux Progresses to Next Level of RAS, December 2010.The more recent Intel Xeon processor E7 family includes additional RAS features, such as Double Device Data C orrection and Partial Memor y Mirroring.

2Source:UniversitySeesMajorSavingswithDataCenterConsolidation,aCiscocustomersuccessstory.http://www.cisco.com/en/US/solutions/collateral/ns340/ns517/ns224/U_of_Colorado_casestudy_nal.pdf.

3 The enterprise capacity planning team should have this historical data available already; its always a good idea to involve them early in the process.

4 For more information about the Sysstat package of tools, visit: http://w ww.go2linux.org/sysstat-linux-performance-monitor-toolkit.

5ThisportingmethodologyisbasedontheSolaristoLinuxPortingGuide,publishedbyHPinSeptember,2009.http://h21007.www2.hp.com/portal/download/les/unprot/ linux/sol_to_linux_port ing_guide.pdf.

INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE,TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRA NTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTELS TERMS AND CONDITIONS OF SALE FOR SUC HPRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER, AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF INTELPRODUCTS INCLUDING LIABILITY O R WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT,

COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT. UNLESS OTHERWISE AGREED IN WRITING BY INTEL, THE INTEL PRODUCTS ARE NOT DESIGNED NO RINTENDED FOR ANY APPLICATION IN WHICH THE FAILURE OF THE INTEL PRODUCT COULD CREATE A SITUATION WHERE PERSONAL INJURY OR D EATH MAY OCCUR.

Intelmaymakechangestospecicationsandproductdescriptionsatanytime,withoutnotice.Designersmustnotrelyontheabsenceorcharacteristicsofanyfeaturesorinstructionsmarkedreservedorundened.Intelreservestheseforfuturedenitionandshallhavenoresponsibilitywhatsoeverforconictsorincompatibilitiesarisingfromfuturechangestothem.Theinformationhereissubjecttochangewithoutnotice.Donotnalizeadesignwiththisinformation.

Theproductsdescribedinthisdocumentmaycontaindesigndefectsorerrorsknownaserratawhichmaycausetheproducttodeviatefrompublishedspecications.Currentcharacterizederrataareavailableonrequest.ContactyourlocalIntelsalesofceoryourdistributortoobtainthelatestspecicationsandbeforeplacingyourproductorder.Copiesof documents which have an order number and are referenced in this document, or other Intel literature, may be obtained by calling 1-800 -548- 4725, or by visiting Intels Web siteat www.intel.com.

Copyright 2012 Intel Corporation. All rights reserved. Intel, the I ntel logo, and Xeon are trademarks of Intel Corporation in the U.S. and other c ountries.

*Other names and brands may be claimed as the property of others. Printed in USA 0112/JRR/HBD/PDF Please Recycle 326480-001US

RISC_vs_CISC_Migration_from_UNIX_RISC_to_Intel_based_Solutions.pdf

Documents

Transcript of RISC_vs_CISC_Migration_from_UNIX_RISC_to_Intel_based_Solutions.pdf