Migration from UNIX/RISC to Intel-based Solutions · Migration from UNIX/RISC and Mainframe to Intel-based Solutions A Practical Migration Guide introduction Many Fortune 500 corporations

Migration from UNIX/RISC and Mainframe to Intel-based Solutions A Practical Migration Guide

introduction

Many Fortune 500 corporations have successfully migrated legacy SPARC/ Solaris and Power/AIX infrastructure to Intel® Xeon® processor-based servers running Linux.* Most have achieved significant business and IT benefits, including better performance and reliability, lower capital and operating costs, and better flexibility and agility for future growth. They have also reduced the load on their data center infrastructure. As you’ll see in the case studies referenced in this paper, the benefits can be substantial, even transformative.

This white paper is designed to help technical decision makers

understand the requirements of a successful migration. It provides

high-level, step-by-step guidelines based on a methodology that has

been used successfully for many years and across many different

migration scenarios.

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 specific 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 Spectrum—from 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.

Wallis Pereira Senior Solutions Architect

Gary Howard Senior Solutions Architect

Sajid Khan Global Mission Critical Initiatives

To learn more about modernizing your mission

critical environment, go to www.intel.com/servermigration

WHitE PAPErriSc MigrationMission-Critical Solutions

Why MigrateThere are a number of reasons why organizations choose to migrate away from legacy UNIX/RISC infrastructure. Many find their existing hardware and software environment is too costly to maintain and support. The high costs are often compounded by the lack of flexibility 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 flexible and affordable computing platform, but are concerned about the cost and risk of migration.

Although careful assessment is always important to confirm 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 refined over more than a decade, services and support are widely available, and most obstacles that are 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 benefits 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 flexibility of IT environments. Intel Xeon processor-based servers running Linux are supported by one of the world’s largest vendor com-munities. Businesses have more hardware, software, and service options, and they benefit from faster innovation and more competitive pricing models.

table of contents

introduction . . . . . . . . . . . . . . . . . . . . . 1

Why Migrate . . . . . . . . . . . . . . . . . . . . . 2

core Migration issues . . . . . . . . . . . . . 3

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

Limiting Outage during the Switchover . . . . . . . . . . . . . . . . . . . .3

the Migration Spectrum— from Simple to complex . . . . . . . . . . 4

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

Remote Office/Retail Computing Applications . . . . . . . . . . . .4

Mission-Critical Common- Off-the-Shelf (COTS) Applications . . .4

Mission-Critical Custom Applications . . . . . . . . . . . . . . .5

Migration Methodology . . . . . . . . . . . 6

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

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

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

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

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

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

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

using tools to Simplify and Accelerate Migrations . . . . . . . 14

conclusion . . . . . . . . . . . . . . . . . . . . . 15

EnvironMEntMEtHodoloGy StEPS

1 . ProjEct PlAnninG

2 . codE convErSion

3 . Proof of concEPt

4 . Solution ArcHitEcturE

5 . Pilot MiGrAtion

6 . rEHEArSAl MiGrAtion

7 . Production MiGrAtion

infrastructure

Remote Office/Retail computing

Mission-critical cotS Applications

Mission-critical custom Applications

table 1 . Identifying the Appropriate Steps for Your Migration.

2

Migrating from unix/RISC to Linux* on Intel® Architecture

Many companies have taken advantage of virtualization during or following their 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 efficiently 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 and disaster 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.

core Migration issues 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 first 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 company’s unique challenges and require-ments, such as success factors, service level agreements (SLAs), enterprise procedures, and political issues.

Although migration is a detailed process with many issues to consider, two core issues arise in most migrations. The first is code and data conversion. The second is limiting the application outage during the switch-over to the new solution.

code and data conversion

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 significant 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 significant bits of a multi-byte number are stored in the memory location with the lowest address. Intel architecture is little endian, so the most

significant bits are stored in the memory location with the highest address. Since this 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.

limiting outage during the Switchover

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 downtime altogether, 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

Migrating from Unix/RiSC to Linux* on intel® Architecture

3

the Migration Spectrum— from Simple to complexMigrations 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.

infrastructure Applications

Examples: DNS, LDAP, web servers, firewalls, backup and restore, file 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, since downtime windows are not a significant 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 computing Applications

Examples: Business applications running at multiple locations, such as remote offices, 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 offices 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.

Mission-critical commercial- off-the-Shelf (cotS) Applications

Examples: Re-hosting core business applications, 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 best to 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


In general, the workflow for a mission-critical migration involves performing a detailed 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 final production migration can be performed quickly and with minimal risk.

The same basic methodology applies to multiple scenarios of varying complexity, including:

• re-hosting an application stack with no software changes . Migration should be relatively simple and straightforward, since only data unique to the enterprise must be transferred.

• re-hosting an application stack with software version changes (e.g., Oracle 9i* 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-hosting application stacks that require significant upgrades (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.

Mission-critical custom Applications

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 significant impact on cost, risk, and timelines.

The time and effort required for code conversion will be roughly proportional to the 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. Once code 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 modified 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 find new developers that understand the lan-guage, whether it’s COBOL, PL/1, another mainframe language, or JCL. The applica-tions running on a mainframe may also be interdependent, making it necessary to 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: www .inteldatacentermigration .com

rEquirEd StEPS

Project Planning

Code Conversion

Proof of Concept


Rehearsal Migration


1

2

3

4

5

6

2

3

rEquirEd StEPS

5


Migration MethodologyEvery migration is different. The follow-ing methodology provides a good starting point for most migrations, but will need to be adapted to address specific 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).

Project Planning

Careful planning lays the foundation for a successful migration. The following steps are recommended.

1 . understand your goals . 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 and other goals provides a framework for decision making throughout the planning process.

2 . define the scope . 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 . define your success criteria . 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 . Simulate tco and return on investment (roi) . Applications are available 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 your Existing Environment . In this step, you perform a detailed as-sessment of your existing environment to 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

replatforming the Enterprise Backbone

The world’s 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 SAP deployment 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-computing-xeon-7500-5600-eli-lilly-case-study .pdf

6


− 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 to determine whether they are com-patible, and, if not, whether suitable alternatives are available.

− Create a profile 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 a hard-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-implement a 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 don’t 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 your new 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 . determine feasibility and identify risks . Based on all the information you 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 your operational environment? Can you be sure of stakeholder support and the funding you need to complete the project?

7 . decide whether or not to proceed . 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 . Preliminary Server Sizing . If you decide to proceed, you will need to assess 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 a quarter. 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 the installation 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.

code conversion

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 appropriate vendor or open source application.

The emergence and adoption of standards such as POSIX.1, UNIX 95, and UNIX 98 has significantly 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


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 application’s 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-user impact 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 team’s 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 avoid architectural 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 the transition, 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)

Building a fluid Environment

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/ virtualization-xeon-5600-california-department-of-water-resources-study .html

9


Proof of concept (Poc)

All complex or mission-critical migrations should 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 disks or 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 or a 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 should have 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 required configurations, 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.

MIgRaTIoN IN The Real WoRld: NCh CoRpoRaTIoN

Accelerating 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-xeon-7540-nch-corporation-cost-savings-study .html

10


− 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, network links, 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 configured 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 specification. By providing hardware support for encryption, it allows IT organizations to implement stronger data protection without slowing down application 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 firmware 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-, and eight-socket configurations that will meet the vast majority of requirements. Larger systems are available from select vendors.

11


− Analyze the data to determine the source of the bottlenecks. Is the hardware 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.


Once you have finished your PoC, you need 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 confident that SLAs can be met, but there are several addi-tional issues to consider.

• robust hardware . 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.

• clustering . 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.

• Horizontal scaling . 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

MIgRaTIoN IN The Real WoRld: UNIveRSITy of ColoRado

large Scale data center consolidationTo 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 was reduced 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 _final.pdf

12


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.

• vertical Scaling . 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 also provide more CPU resources (cores, cache, and bandwidth), and come in larger server configurations to support heavier workloads.

Pilot Migration

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 an off-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, so extensive 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 the application, 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-Hosting Modern Mainframe Applications

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 customers and 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. www .inteldatacentermigration .com

13


rehearsal Migration

Ensuring a successful switchover to the new solution requires careful preparation. Your PoC migration steps were not opti-mized for simplicity, speed, or efficiency. 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 refine 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-migration steps, 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 the time 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.


By the time you reach this point, you should have full confidence 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.

using tools to Simplify and Accelerate MigrationsA 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 first migration from a UNIX/RISC platform to Linux on Intel architecture it is probably best to work with an experienced vendor to determine best-fit tools and processes for your spe-cific 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 significant 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 specific goals and requirements.

14


Option 1: Oracle export/import utility.

This is the simplest method for migrating an 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.

option 2: oracle Streams .

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 third intermediate 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.

conclusionIntel 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


For more information and resources, visit http://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 at www .inteldatacentermigration .com


1 For detailed descriptions of the RAS features provided in the Intel Xeon processor 7500 series, 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 Correction and Partial Memory Mirroring.

2Source:“UniversitySeesMajorSavingswithDataCenterConsolidation,”aCiscocustomersuccessstory.http://www.cisco.com/en/US/solutions/collateral/ns340/ns517/ns224/U_of_Colorado_casestudy_final.pdf. 3 The enterprise capacity planning team should have this historical data available already; it’s always a good idea to involve them early in the process. 4 For more information about the Sysstat package of tools, visit: http://www.go2linux.org/sysstat-linux-performance-monitor-toolkit. 5Thisportingmethodologyisbasedonthe“SolaristoLinuxPortingGuide,”publishedbyHPinSeptember,2009.http://h21007.www2.hp.com/portal/download/files/unprot/linux/sol_to_linux_porting_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 GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTEL’S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER, AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR 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 NOR INTENDED FOR ANY APPLICATION IN WHICH THE FAILURE OF THE INTEL PRODUCT COULD CREATE A SITUATION WHERE PERSONAL INJURY OR DEATH MAY OCCUR.

Intelmaymakechangestospecificationsandproductdescriptionsatanytime,withoutnotice.Designersmustnotrelyontheabsenceorcharacteristicsofanyfeaturesorinstructions marked“reserved”or“undefined.”Intelreservestheseforfuturedefinitionandshallhavenoresponsibilitywhatsoeverforconflictsorincompatibilitiesarisingfromfuturechangesto them.Theinformationhereissubjecttochangewithoutnotice.Donotfinalizeadesignwiththisinformation.

Theproductsdescribedinthisdocumentmaycontaindesigndefectsorerrorsknownaserratawhichmaycausetheproducttodeviatefrompublishedspecifications.Current characterizederrataareavailableonrequest.ContactyourlocalIntelsalesofficeoryourdistributortoobtainthelatestspecificationsandbeforeplacingyourproductorder.Copies of 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 Intel’s Web site at www.intel.com.

Copyright © 2012 Intel Corporation. All rights reserved. Intel, the Intel logo, and Xeon are trademarks of Intel Corporation in the U.S. and other countries. *Other names and brands may be claimed as the property of others. Printed in USA 0112/JRR/HBD/PDF Please Recycle 326480-001US

Documents

Migration from UNIX/RISC to Intel-based Solutions · Migration from UNIX/RISC and Mainframe to Intel-based Solutions A Practical Migration Guide introduction Many Fortune 500 corporations