WHITE PAPER RISC Migration Mission-Critical Solutions

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 youll 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.
Wallis Pereira
Senior Solutions Architect

Gary Howard
Senior Solutions Architect

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

Sajid Khan
Global Mission Critical Initiatives

To learn more about modernizing your mission critical environment, go to www.intel.com/servermigration

Migrating from Unix /RISC to Linux* on Intel Architecture

Methodology Steps Environment

Infrastructure Remote Office/Retail Computing Mission-Critical COTS Applications Mission-Critical Custom Applications 1. Project Planning 2. Code Conversion 3. Proof of Concept 4. Solution Architecture 5. Pilot Migration 6. Rehearsal Migration 7. Production Migration

Table 1. Identifying the Appropriate Steps for Your Migration.

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

Why Migrate
There 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 organizations 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 worthwhile 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 industrystandard 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 reliability, availability, and serviceability (RAS) features integrated at the silicon and system level to provide the data integrity and system resilience needed in missioncritical 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 processorbased servers running Linux are supported by one of the worlds largest vendor communities. Businesses have more hardware, software, and service options, and they benefit from faster innovation and more competitive pricing models.

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.

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, conversion 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 multibyte 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 straightforward to convert data when it is transferred 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 planning, 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.

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 companys unique challenges and requirements, such as success factors, service level agreements (SLAs), enterprise procedures, and political issues.

Migrating from Unix/RISC to Linux* on Intel Architecture

The Migration Spectrum From Simple to Complex

Migrations 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. Required Steps 1 Project Planning 2 Pilot Migration 3 Production Migration 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 performed, 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. Required Steps 1 Project Planning 2 Code Conversion 3 Solution Architecture 4 Pilot Migration 5 Rehearsal Migration 6 Production Migration One of the primary challenges of application 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 replicate 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 CommercialOff-the-Shelf (COTS) Applications Examples: Re-hosting core business applications, such as SAP, Oracle eBusiness Suite,* and associated databases Required Steps 1 Project Planning 2 Code Conversion 3 Solution Architecture 4 Pilot Migration 5 Rehearsal Migration 6 Production Migration In addition to hardware and OS migrations, mission-critical COTS applications can be migrated at the database layer, the application 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 migration. 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.

Migrating from Unix/RISC to Linux* on Intel Architecture

In general, the workflow for a missioncritical migration involves performing a detailed assessment, followed by any required code conversion and a proof-ofconcept (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 workloads 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 simultaneous 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 example, 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 Required Steps 1 Project Planning 2 Code Conversion 3 Proof of Concept 4 Solution Architecture 5 Rehearsal Migration 6 Production Migration 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 functionality, 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 applications tends to be more challenging, but can be straightforward if the code is modern, well written, and well documented. Migrating older custom applications can be quite challenging. A 30-year-old mainframe 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 language, whether its COBOL, PL/1, another mainframe language, or JCL. The applications 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 example of mainframe migration methodology, see Re-Hosting Mainframe Applications on Intel Xeon Processor-based Servers at: www.inteldatacentermigration.com

Migrating from Unix/RISC to Linux* on Intel Architecture

Migration Methodology

Migration in the Real World: Ely Lilly

Replatforming the Enterprise Backbone The worlds 10th largest pharmaceutical company has completed about 70 percent of an enterprise-wide transformation 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-criticalcomputing-xeon-7500-5600-eli-lillycase-study.pdf

Every migration is different. The following methodology provides a good starting point for most migrations, but will need to be adapted to address specific requirements. 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 architecture, including strategic or tactical business needs, the need to refresh aging infrastructure, cost reduction, performance, energy efficiency, reliability, space reduction, and the desire to standardize or virtualize infrastructure. 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 applications, 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 number 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 service 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. A  ssess Your Existing Environment. In this step, you perform a detailed assessment 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 provides 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 sidebar 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 application? If not, what impact will these differences have on your solution, your users, and your migration?

Migrating from Unix/RISC to Linux* on Intel Architecture

 Compile an equipment and application inventory of your existing environment. If no credible inventory exists, you can perform this manually or you can license software that automatically 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 compatible, 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 dependencies 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 migrating 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 requirements for storage, servers (CPU, memory, and I/O), the network, and SLAs. Consider backup and disaster 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 application 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 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 feasibility of your migration and identify potential risks. Is it feasible from a technical standpoint? Can you meet requirements for performance, scalability, availability, security, and data integrity? Do you have the necessary experience, skills and resources available 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 determine whether it makes sense to proceed with the particular migration.

Migrating from Unix/RISC to Linux* on Intel Architecture

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 proofof-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 hardware before the application has been tested on the new system architecture. Application performance can differ dramatically in going from one architecture to another, and only performance testing on similar platforms can provide accurate performance estimates. 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 straightforward, since the requirements will be very similar to your legacy infrastructure. Determining CPU requirements, however, is not so simple. There are both architectural and generational differences to consider, including the numbers of cores, threads, cache, instructions per clock cycle, and many other factors. One way to approach this task is to use performance monitoring 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 network 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 configured to monitor performance metrics over longer intervals. Use these tools to collect data through a normal business cycle. This is typically 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 collecting data for your specified period, the sizing tool will analyze the data and recommend an appropriate Intel Xeon processor-based server.

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 complexities that must be dealt with in most code conversion efforts. In general, the more compliant the application source code is with language, coding, and run-time standards, the easier it will be to port to the new computing platform. 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.

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, documentation, porting tools, and developers with appropriate skills and experience. For large and complex custom applications,

Migrating from Unix/RISC to Linux* on Intel Architecture

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, including the tools used for source code management, the build environment, installation, application management, development, profiling and performance measurement, testing, and documentation. Include third-party products, such as libraries, applications servers, and application completers. 5. Identify and assess the likely impact of differences in the operating systems, 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 delivering your application on the new target system. This can include the need for data conversion, uptime support during the transition period, product installation 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 development procedures as needed. 9. Clean up the application source code, identifying and removing architectural dependencies and nonstandard practices where possible. 10. Extend the application source code to support the new target platform. This can include the addition of conditional 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 customer 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 planning 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 applications 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 contain rising costs. By virtualizing and consolidating the entire infrastructure, including mission-critical enterprise applications, on Intel Xeon processorbased 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-californiadepartment-of-water-resourcesstudy.html

Migrating from Unix/RISC to Linux* on Intel Architecture

Proof of Concept (PoC)

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 performance 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-migrationxeon-7540-nch-corporation-costsavings-study.html

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 capacity, 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 system. 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 reconfigure 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.

10

Migrating from Unix/RISC to Linux* on Intel Architecture

 Optimizing performance is a standard part of the PoC and can entail a significant amount of time so build this into your schedule. Reiterative adjustments 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 environment 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.

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

11

Migrating from Unix/RISC to Linux* on Intel Architecture

Migration in the Real World: University of Colorado

Large Scale Data Center Consolidation To address rising costs, the University of Colorado migrated its missioncritical IT environment from RISCbased 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

 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 production 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, stepby-step documentation for those processes may not be necessary.  Still other steps, such as setting environmental parameters for the application, lie somewhere in between. The processes for setting those parameters will have to be repeated. The processes for determining the correct settings will not. Adjust your documentation accordingly. 15.  Review the PoC and documentation with the PoC team.

Solution Architecture 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 determined that the application runs on the hardware and are confident that SLAs can be met, but there are several additional issues to consider. Robust hardware. With most migrations, you automatically gain performance, scalability, and RAS when you replace older equipment with more robust, newer hardware. 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 specifically for mission-critical environments and provides advanced support for data integrity and system resilience at the silicon 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 distributions. 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 individual servers. This can be an excellent approach for presentation layer services, which tend to scale well across multiple servers through workload balancing. If

12

Migrating from Unix/RISC to Linux* on Intel Architecture

a server fails, its workload automatically fails over to the remaining servers, providing high availability as well as scalability. 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, performance is scaled by adding resources to the server or upgrading to a larger system. Applications that are appropriate for vertical scaling tend to be mature or single-purpose applications that exhibit a high degree of scalability, such as databases 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 functionality 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 mainframe 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 information about the HSBC methodology and migration experience. www.inteldatacentermigration.com

13

Migrating from Unix/RISC to Linux* on Intel Architecture

Rehearsal Migration Ensuring a successful switchover to the new solution requires careful preparation. Your PoC migration steps were not optimized 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 minimizes 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 reordering 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 production 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. Production Migration 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 Migrations

A broad range of tools are available to help with migrations, including capacity 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 specific migration. Many server, OS, and application 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 different tools that can be used to migrate an Oracle database to Intel Xeon processorbased servers. Multiple options are available 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

Migrating from Unix/RISC to Linux* on Intel Architecture

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 processor-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 processorbased 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.

Conclusion
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 application 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

Migrating from Unix/RISC to Linux* on Intel Architecture

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. 2 Source: University Sees Major Savings with Data Center Consolidation, a Cisco customer success story. 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; its 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. 5 This porting methodology is based on the Solaris to Linux Porting Guide, published by HP in September, 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 INTELS 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. Intel may make changes to specifications and product descriptions at any time, without notice. Designers must not rely on the absence or characteristics of any features or instructions marked reserved or undefined. Intel reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them. The information here is subject to change without notice. Do not finalize a design with this information. The products described in this document may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request. Contact your local Intel sales office or your distributor to obtain the latest specifications and before placing your product order. 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 Intels 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