Global energy leader streamlines business applications and IT infrastructure with SAP and IBM

Published on 18-Jul-2011

Validated on 07 Jan 2013

Customer:
Global energy leader

Industry:
Energy & Utilities

Solution:
IT/infrastructure, Business Resiliency, Energy Efficiency, High Availability , Infrastructure Simplification, Optimizing IT, Optimizing IT, Virtualization, Virtualization - Server, Workload Management

IBM Business Partner:
SAP, EWB Consulting Ltd.

Overview

The customer is a very large enterprise engaged in the exploration, development, production, transmission, distribution and supply of natural gas and oil. It also has a number of interests in power generation. The Group’s worldwide operations are organized on a regional basis. In 2009 the company employed more than 6,000 people, and sales reached more than £10 billion.

Business need:
Customer objectives included: Encompass all core business processes within the SAP business applications environment; consolidate more than 75 x86 servers within a highly complex IT infrastructure; transform dedicated hardware into virtual machines in order to develop system flexibility and meet strategic goals for growth within the next five years; reduce expenditure on hardware maintenance and administration; eliminate risk and dependency on a single data center by implementing high availability and disaster recovery solutions; optimize the IT footprint in terms of space and energy.

Solution:
Running on extremely short turnaround times, IBM UK Systems and Technology Group and Technical Solution Sales teams analyzed the existing infrastructure then provided a detailed assessment of SAP application behavior and a solid baseline for sizing and virtualizing the SAP server landscape by using the IBM Insight Tool. Chose the IBM POWER platform to meet consolidation targets and apply latest PowerVM and AIX virtualization technologies. IBM Global Technology Services performed the landscape deployment, covering hardware and system software installation and configuration.

Benefits:
The number of physical servers was reduced by 95 percent, from 80 servers to four. Average server utilization improved by up to 60 percent. The customer is able to deliver SAP application services at a lower cost to its lines of business while reducing its total costs of ownership. The customer can respond much faster to changing loads and SAP instance requirements, for example: tTemporary SAP test environments can be deployed in minutes compared to days or even weeks and load peaks can be handled by load balancing within virtualized IBM Power servers in a non-disruptive manner.

Case Study

About this paper

This brochure outlines how IBM helped a world leader in energy (natural gas exploration and distribution) modernize and simplify its existing, siloed HP infrastructure into a state-of-the art IT backbone. Its business-critical SAP components now run in a fully virtualized and resilient IBM POWER and AIX environment, making extensive use of IBM’s latest technologies. The transformation phases are described, from early system design and sizing to the optimized migration of manifold ABAP and Java SAP systems, and, finally, the implementation and exploitation of new virtualization technologies.

Customer Objectives

  • Encompass all core business processes within the SAP business applications environment.
  • Consolidate more than 75 x86 servers within a highly complex IT infrastructure.
  • Transform dedicated hardware into virtual machines in order to develop system flexibility and meet strategic goals for growth within the next five years.
  • Reduce expenditure on hardware maintenance and administration.
  • Eliminate risk and dependency on a single data center by implementing high availability and disaster recovery solutions.
  • Optimize the IT footprint in terms of space and energy.
  • Complete SAP application migration and platform transition within a six-month period.
  • Minimize impact on end users during transition.
  • Provide Level 1 support on infrastructure, while providing existing partner Accenture with necessary tools to continue to provide SAP application and BASIS support.

IBM Solution
  • Running on extremely short turnaround times, IBM UK Systems and Technology Group and Technical Solution Sales teams analyzed this major customer’s existing infrastructure and its new requirements.
  • Provided a detailed assessment of SAP application behavior and a solid baseline for sizing and virtualizing the SAP server landscape by using the IBM Insight Tool.
  • Chose the IBM POWER platform to meet consolidation targets and apply latest PowerVM and AIX virtualization technologies (e.g. Multiple Shared Processor Pools and Workload Partitions).
  • Leveraged Power Systems Capacity-on-Demand capabilities to maintain service levels, even in cases of outages and failures.
  • IBM Global Technology Services performed the landscape deployment, covering hardware and system software installation and configuration.
  • IBM partnered with EWB Consulting Ltd. (http://www.ewb-consulting.co.uk) to perform accelerated SAP platform migrations to IBM AIX.

Customer Benefits
  • The number of physical servers was reduced by 95 percent, from 80 servers to four.
  • Average server utilization improved by up to 60 percent.
  • The customer is able to deliver SAP application services at a lower cost to its lines of business while reducing its total costs of ownership.
  • The customer can respond much faster to changing loads and SAP instance requirements, for example:
  • Temporary SAP test environments can be deployed in minutes compared to days or even weeks
  • Load peaks can be handled by manual and automatic load balancing within virtualized IBM Power servers in a non-disruptive manner.
  • Business applications and infrastructure have been standardized and harmonized, increasing SAP application availability while reducing operational efforts and paving the way for continued innovation within the company’s SAP team.

The customer: starting point and objectives

The customer is a very large enterprise engaged in the exploration, development, production, transmission, distribution and supply of natural gas and oil. It also has a number of interests in power generation. The Group’s worldwide operations are organized on a regional basis. In 2009 the company employed more than 6,000 people, and sales reached more than £10 billion.

When IBM first became involved, the company was running its business-critical SAP systems on a variety of ageing Intel-based HP servers with Oracle databases. The Group made a strategic decision to consolidate all of its core business processes within one SAP environment. The company’s existing data center represented a huge business risk that had to be addressed, as forecast growth showed that it would run out of space and power within six months.

Making a strategic choice
The company’s previous IT vendor submitted an expensive plan for little more than a hardware upgrade and failed to address the company’s core issue of limiting business risk.

In contrast, the IBM team’s in-depth knowledge of SAP technologies and business applications allowed it to create a strong business and technical case regarding the advantages of matching SAP with the IBM POWER platform.

IBM proposed that the renewal of these systems should be aligned with a strategic platform decision covering at least the next five years, with a roadmap for future growth, platform stability and the latest IBM technologies.

The IBM solution addressed the longer-term strategy for managing growth within a confined physical space, delivering lower operating costs and simplifying the IT landscape. To meet anticipated demand, planned processing headroom allowed for growth to double over five years. Intelligent virtualization helped increase overall server efficiency, as well as reducing Oracle database license fees, and cutting total costs of ownership.

The solution consolidated all core business processes to SAP Business Suite software and replaced a mix of legacy and SAP applications. This created better integration of data and transparency of tasks, designed to reduce the processing workload, which in turn would reduce the immediate infrastructure investment costs. The single focus on using SAP Business Suite meant that this environment would become mission-critical for the customer. The organization therefore required a resilient IT architecture, which would include a second data center for high availability and disaster recovery purposes.

The ability to listen to and understand the customer’s specific requirements was essential. Successful migration references of existing systems onto the AIX platform provided positive proof that IBM would be able to deliver seamless transition to the new SAP Business Suite environment and infrastructure, lowering the risk for the client.

Analyzing the existing landscape and resources
Prior to migration, the older legacy and SAP environments consisted of sandbox, development, quality assurance, regression, training and production stages (including site fail over). These encompassed SAP components such as SAP ERP 6.0 and SAP NetWeaver Business Warehouse 7.0 – each comprising an ABAP and Java stack – a federated SAP NetWeaver Enterprise Portal 7.0 and an xApp for Emissions Management running on Java WEB Application Server 7.0. All these components were selected for migration.

Further environmental support components such as SAP Solution Manager and Systems Landscape Directory were also included in the migration to the IBM AIX operating system platform. The source systems all ran on Microsoft Windows with Oracle databases and ABAP systems, and consisted of database sizes of just under 1 TB and Java systems of approximately 150 GB in volume.

The organization had a considerable number of ‘flat file’ interfaces, both in and out of the SAP environment. These interfaces required careful testing ahead of a successful migration, in order to ensure that any dependencies on the SAP ecosystem were also included in the transformation and transition project, to avoid the risk of disrupting established business workflows after the migration.

For a quantification of the existing SAP workload, IBM ran the IBM Insight for SAP tool across selected SAP systems, designed to understand the utilization and behavior of each component. The results provided a solid base for sizing and projecting the final target systems. The Insight Tool also helped validate the assumptions being made in the design of the final IT architecture.

Beyond scaling and performance criteria, the proposed solution had to be integrated into an existing non-IBM IT environment, comprised of EMC SAN-based storage, Symantec NetBackup for backup and restore, and BMC Patrol, which provided the SAP application and OS-level monitoring.

Finally, Accenture’s involvement in seamlessly supporting the new, virtualized IBM server environment was an essential consideration, as it was already providing the global energy giant with 2nd line SAP Application and BASIS support.

The IBM Insight Tool
The IBM Insight for SAP utility program provides workload analysis for in-production SAP system landscapes. This service and utility are provided free of charge by IBM.

The Insight Collector communicates with the SAP system and monitors workload and utilization statistics at an operating system and SAP application level. These statistics are recorded for processing and analysis. IBM provides the client with a detailed performance report specifying the workload and utilization characteristics/behavior pattern of their SAP instances and their underlying infrastructure.

AIX Workload Partitions (WPARs)
In contrast to LPARs, which are created and managed at the server firmware level, AIX WPARs are software partitions that are created from, and share the resources of a single instance of the AIX operating system. This reduces the number of operating system instances to be maintained while providing the isolation necessary to protect applications.

Applications running within WPARs on an identical host AIX operating systems also share memory in a highly dynamic manner. These reductions in physical and operational demands make WPARs an excellent consideration versus shared LPARs, in particular for smaller SAP instances.

SAP fully supports System WPARs. System WPARs are autonomous virtual system environments that have their own private file systems, users and groups, login, network space, and administrative domain. To users and applications, a System WPAR appears almost exactly like a full AIX system.

Defining the IBM infrastructure solution

Fully virtualized system architecture and sizing approach
The logical system landscape was very mixed, and application layouts varied with components and environments. The first step was to standardize the architecture for the SAP components. The next stage was to consider the availability and recovery requirements (RPO, RTO) for each component.

To provide scalability and resilience, the SAP production environment was deployed as a distributed 3-tier environment. In contrast, non-production systems for development and quality assurance were deployed as centralized, 2-tier instances.

In order to create a high level of physical consolidation and its associated synergies, the SAP systems were deployed in a fully virtualized setup. The IBM Power platform offers several methods to ensure that an instance receives the required or desired resources. These mechanisms are available at the hardware-based hypervisor level using IBM PowerVM to create Logical Partitions (LPARs), and at the AIX operating system level with Workload Partitions (WPARs) utilizing Workload Manager (WLM).

The proposed design provided the flexibility to isolate workload into separate individual partitions, consolidate them, or use a mix of both approaches. This methodology required careful study, and was meticulously planned during the initial project design phase.

The core virtualization approach is based on multiple competing LPARs, which receive their resources from a shared resource pool. Virtualization delivers major benefits such as increased efficiency of system utilization and proper resource distribution, especially during times of peak loads and stresses.

The initial Insight Tool study showed that typical server utilization under the existing customer’s architecture was somewhat lower than 10 percent on average. By driving utilization for the combined SAP workload up to 80 percent, the hardware infrastructure needed for the same transaction processing workload was dramatically reduced.

Since the customer uses Oracle databases on a per-processor licensing model, multiple shared processor pools were introduced. This helps reduce Oracle license requirements and associated costs, and retains the flexibility and benefits of a fully virtualized environment.

One shared processor pool is used for non-Oracle LPARs, and a separate pool with fewer maximum processor counts is used for LPARs exclusively running Oracle database instances. This allows the company to easily share, modify and restrict (as required) the number of processors available to Oracle.

To do so, dynamic LPAR features can be used to add, move and remove processor, memory and I/O resources between LPARs according to the changing needs of the system during SAP application operations. These resource modifications are non-disruptive and can be used while the database and SAP applications are up and running without impact on the end-user.

Additionally, the IBM PowerVM virtualization approach encompasses both external IP networks and the internal SAN fabric. By exploiting the Virtual I/O Server (VIOS) feature of PowerVM, clients can minimize external connectivity with LPARs by sharing host bus adapters and network interface cards. This reduces the overall network and SAN port numbers, which saves the client additional switching and director technologies, as well as reducing system management workload.

In combination with Network Installation Manager (NIM), which provides tools to deliver a standard AIX image on new LPARs, the provisioning of new SAP systems can be accomplished without the lengthy delays and operational costs of deploying physical servers and installing the software stack from scratch.

AIX V6 Workload Partitions (WPARs) have been used for development, quality assurance, temporary systems and production and regression application servers. The SAP application server LPARs were configured with up to seven WPARs, each supporting a different SAP instance (SID) and able to utilize different versions of Java code.

This allows the company to reduce the total LPAR count, which in turn minimizes implementation and maintenance effort and costs. In this customer’s case, new WPARs can be created in some 3 or 4 minutes, and started in around 10 seconds.

The company decided to fully populate the servers with processors and memory in order to ensure that any future resource requirements were available without the need for upgrade outages.

When additional resources were in fact required later in the project, temporary Capacity-Upgrade-on-demand (CUoD) and memory were easily activated, immediately providing the necessary capacity. Subsequently, permanent activation keys were ordered and adjustments to system resources do not require any downtime.

The virtualized SAP landscape described above is deployed on a pair of IBM Power 570 servers with POWER6® processors in each of the two data-centers that make up part of the broader infrastructure. Note that the infrastructure comprises a number of elements that are outside the scope of this document, such as the EMC-based SAN fabric.

Each Managed System has been configured with redundant VIOS (Virtual I/O Server) partitions. These special-purpose LPARs provide virtual Ethernet, virtual SCSI and Node Port Virtual ID Virtualization (NPIV) capabilities. VIOS features allow the company to gain higher utilization and flexibility from the hardware.

Making use of virtualized I/O provided by PowerVM’s VIOS makes it possible to create and bring new LPARs into service very quickly, often without the need for additional hardware. In the event of an unexpected problem, multiple redundant VIOS LPARs are configured to maintain availability, and allow system maintenance work to be performed without the need for downtime.

Overall, the consolidation methodology resulted in a logical system setup and partition sizing as depicted in Figure 5. The image represents the system design, describing how the server has been split into various sections. The server is broadly categorized by three pools, including an application pool, a virtual I/O host pool, and a CUoD or spare pool.

The application pool is split further into SAP database, central services and SAP application server LPARs. The application and non-production pool are configured into WPARs, while each database is configured in a dedicated LPAR. This configuration reduces total database license fees for the organization as a whole.

All except the VIOS & NIM LPARs are booted from SAN-attached EMC Symmetrix and Clariion storage devices. EMC Symmetrix DMX4 storage is used for production, with EMC Clariion CX4 960 providing storage for non-production systems.

The storage LUNs are protected using RAID 5 (7+1) and EMC PowerPath multipath driver provides load balancing and redundant paths between AIX and the back-end storage.

SAN resilience is provided by using a dual fabric topology, made up of Cisco MDS 9513 Director Class switches. NPIV has been used to simplify management and improve performance by extending the existing dual fabrics. This allows storage administrators to create aliases and zones directly to an LPAR’s virtual Fibre Channel adapters. NPIV is transparently supported by PowerVM’s VIOS and in the described scenario NPIV is used for all non-operating-system (rootvg) LUNs. All LUNs containing the AIX rootvg SAN boot devices were attached using the traditional virtual SCSI (vSCSI) setup.

vSCSI allows multiple LPARs to share bandwidth provided by the HBAs owned by the VIOS. The vSCSI setup was configured in order to support the AIX LPARs booting from the EMC Clariion SAN when using NPIV with Cisco Fabric switches at the current firmware level. The switch firmware could not be updated to allow NPIV support, as the later firmware levels did not support other non-SAP applications running in the company. vSCSI also allows the VIOS to share a LUN between multiple LPARs.

The IBM Global Technology Services implementation team managed to combine two levels of SAN virtualization, leading to a high degree of flexibility and I/O throughput, while maintaining the existing infrastructure. For example, the VIO-based LAN setup was seamlessly integrated with the company’s pre-existing Cisco-based Ethernet network.

During implementation of the numerous Basis systems, the AIX Network Installation Manager (NIM) was used to streamline the installation of AIX and VIOS LPARs using a central software repository.

The NIM’s customization facilities were applied to the standardized software images on the central NIM server repository. NIM automated many time-consuming tasks, such as the configuration of network settings, performance monitoring, security, adding user groups and additional software. It also automated system backups. This reduces the overall time and effort required to implement a solution, providing excellent productivity gains.

The NIM will continue to service future installations, support, maintenance, backups and restores due to the speed, efficiency and consistency that it provides. A secondary NIM server, with an alternate NIM Master for redundancy purposes, has been configured in each data center for long-term use at the company.

Making core SAP applications resilient
Landscape resiliency is based on two Power 570 servers in two IT sites. The four servers are clustered for mutual failover using the IBM PowerHA™ cluster solution. The single-point-of-failure (SPOF) of each business-critical SAP system of database and central services is maintained within dedicated PowerHA resource groups, which allow for autonomous and specific quick recovery actions.

For example, one specific cluster action is the extremely quick take-over of the SAP Central Services, which are implemented as SAP Replicated Enqueue Server (SAP ERS) setup.

Since the critical SAP production systems are operated in three-tier mode, an “n + 1” high availability mechanism can easily be implemented for the SAP application servers. To protect the system against the non-availability of a server node, multiple application server instances per production system, such as an SAP NetWeaver Portal, were distributed across two clustered Power 570s.

In the event of a complete shutdown of one of the servers, the sizing of the LPARs and resource pools is designed to allow the remaining Power 570 server in the cluster to run the entire production workload.

Resource pooling among LPARs and the ability to set higher scheduling priorities for performance-critical SAP instances (using PowerVM weightings, for example) provides an ideal complement to automated cluster failover. Production partitions being moved to a standby server maintain a higher priority over non-production systems, and retain their processing cycles at the cost of lower-priority functions, such as testing and development LPARs. An RTO of 4 hours was set for Disaster Recovery (DR), which was built into the DR planning. This type of approach is widely adopted by clients running SAP applications on IBM Power servers.

The ability to restore production services in the DR location depends on a number of factors, including the cross-site replication solution (disk or database controlled), the operational procedures at both sites, the nature of the disaster for which recovery is required (e.g. controlled or rolling), and the ability of SAP / Oracle to recover and restart, based upon the data at the DR site (RPO aspects).

IBM offers excellent services capabilities to advise clients on the appropriate planning and implementation of DR capabilities, including those situations where the DR solution is based on components from multiple vendors.

Joint services to implement the design

Landscape build-up by IBM Global Technology Services
IBM Global Technology Services supplied skilled professionals with real-world experience of SAP application migrations, and proved to be dynamic and flexible in fulfilling the customer’s wishes. Services provided at various stages of the project included workshop, design, build, testing, service introduction, updates and support.

In February 2010 the company asked IBM Global Technology Services to provide project management, a systems architect, and AIX and PowerHA specialists with deep knowledge and experience of the design and implementation of IBM Power servers for SAP migration projects.

The proposed design was signed off in March 2010 with the final migration go-live date set for October 2010. Apart from setting up the new virtualized IBM Power environment, the solution needed to be integrated into the existing non-IBM IT landscape with minimal disruption to ongoing business processes for the organization.

After two Power 570 servers had been commissioned in each of the two data centers, the NIM and VIOS LPARs were built, providing the core for the application LPARs. Redundant VIOS provide the virtualized storage and networks for the application LPARs to be populated by NIM with preconfigured OS and SAP software images.

While the builds were in progress, the PowerHA specialist worked with IBM Training and Education to provide the client with bespoke training. The tailored lesson covered IBM POWER-related technologies that were new to the company, and covered hot topics from six IBM public classes.

This private tutorial enabled the company’s technical staff to understand the features used in the solution at a time and place that suited them best.

To accommodate incremental testing and contingency requirements for the company, IBM Global Technology Services demonstrated its flexibility by doubling the size of the build team to deliver on an accelerated project schedule. Split into two groups, one group concentrated on building the virtualization setup and the other concentrated on resiliency by designing PowerHA Clusters. The combined team continued to progress by implementing sandbox, regression, development, QA, production and other environments.

Skills transfer to customer employees and ongoing support was provided after the handover of each environment, and the SAP BASIS team installed and configured the SAP components. Performance monitoring and tuning tasks were completed with every additional system in order to best leverage the company’s new hardware and PowerVM capabilities.

Throughout all project phases, IBM Global Technology Services made full use of reusable assets related to the design, scripts and documentation templates to deliver the project on schedule, using best practice and the team’s accumulated experience gained from many previous SAP migrations. A ‘Build Diary’ was used to capture the completion of every task, the individual who completed it, and the date it was carried out for each system/environment. Virtualization and PowerHA worksheets were used to design and document specific configurations, to ensure that systems were built in a consistent manner throughout the organization.

Implementation of PowerHA cluster and redundant IT centers
PowerHA is used to protect the database and central server tiers of the production and regression environments by eliminating single points of failure. The Power 570 servers and AIX operating system already provide high reliability, availability and serviceability (RAS) features.

PowerHA adds to the existing list of protection and security by monitoring the environment and moving applications to an alternative system if one is compromised. This is vital in the event of a catastrophic hardware or operating system failure, but is also useful in moving and keeping applications available during planned system downtime or maintenance.

The SAP Replicated Enqueue setup was implemented for the Central Services instances, providing cross-server mirroring of the enqueue table. Should the primary enqueue process – or the server it is running on – fail, the Enqueue table, which represents all transactions and helps to lock tables on transaction level and thus is highly critical, can be re-accessed very quickly from the replicated data on the standby system without the time-consuming task of rebuilding from disk.

To integrate SAP ERS functionality with IBM PowerHA clustering software, the IBM team brought in advice and guidance from the IBM SAP Competence Center (ISICC) based in Walldorf, Germany. Experts at the SAP on AIX development team and at ISICC had been working on a solution to integrate SAP with PowerHA using start, stop and application monitors to make the integration as seamless as possible.

Solution implementation is made simple through the use of a single central XML-like configuration file. The core functionality is provided using library files that create log files following SAP and PowerHA guidelines.

Different log levels are configurable to make debugging and timing of the cluster more convenient. The scripts automatically recover from a one-node situation, initiate a failover to get the Replicated Enqueue table, and then notify the administrators or a restart to be triggered.

PowerHA can also provide application monitoring and promote self-healing features, and move the application to another system if necessary. The company decided to implement this feature of PowerHA in phase two of the project. As for the ERS clustering, the application monitoring scripts provided by the ISICC will be used to monitor, restart and or move applications to keep them available.

Both IBM configurations are based upon production in the primary site and non-production (including full-sized regression environments) and disaster recovery in the secondary site. This is a common data-center pattern, adopted by many IBM SAP clients.

In the event of DR actions being invoked, all the resources of the secondary site are allocated for production workload. This saves having to provide the physical infrastructure for both regression and DR (i.e. two production servers), as the company would normally either use regression or DR environments, and usually never both concurrently.

Both environments can run simultaneously if required, but would mean that resources would be less than 100 percent of production for each. Using autonomous hypervisor mechanisms for dynamic load balancing and peak load compensation described earlier in this document, the DR environment has sufficient capacity on a day-to-day basis to run the production workload. On top of that, in the event of a disaster during a peak load period, incremental CUoDs compute resources can be allocated and activated in a timely, non-disruptive manner.

The PowerHA for SAP Package
The PowerHA for SAP Package is a set of documentation and template scripts that provides guidance for making core SAP single- and dual-stack systems highly available and disaster-proof. The central focus is on how to install the SAP application instances and place them under PowerHA control.

Following the guidelines and scripts provided, the system is quick to set up and easy to support and maintain from end-to-end hardware virtualization to the SAP application stack.

Reusing and standardizing assets creates higher reliability and easier support and maintenance of the implemented cluster setup. The PowerHA for SAP Package is available as a download from IBM Developer Works.

SAP platform migration
While migrating live SAP systems between operating systems and databases is not an overly complicated procedure, it does require detailed planning and a structured methodology to minimize business disruption and manage the technical risks that are associated with any major IT project.

Even though an operating system and database migration project involves no change to application functionality, to deliver a successful and stable environment on changed IT infrastructure requires a project team with skills beyond the business-as-usual BASIS and SAP NetWeaver disciplines.

During the migration planning phase, the company preferred a ‘Big Bang’ cutover strategy, with all SAP software components of a specific landscape type (such as development and production systems) being migrated during the same downtime window. The production systems cutover included all software migrations and types (ECC-ABAP, ECC-Java, BI-ABAP, BI-Java and EP) during the same downtime window.

The poor performance of the legacy systems posed a particular challenge. The individual production databases were all between 500 GB and 750 GB, and initial tests of the SAP ERP ABAP system predicted that export would take more than 72 hours.

The limitations of SAP tools for optimizing Java migrations (specifically SAP NetWeaver Portal) became the driving factor in sequencing the import and post processing of all five software components.

An overview of the challenges:

  1. ‘Big Bang’ migration required five production systems to be exported and imported in parallel.
  2. Limited BASIS resources required careful coordination and management, not just for the physical migration activities but for the vanilla builds and tests, whilst also contending with business-as-usual pressures.
  3. Poorly performing legacy infrastructure required considerable tuning and sequencing of the export process to meet the downtime window.
  4. SAP tools for optimizing Java migrations had a number of limitations.

The migration program put in place created an overlap of vanilla SAP builds with technical test migrations also providing for unit, integration and performance test requirements.

From a technical perspective, the sequence of test migrations began with a Proof of Principle, moved on to iterative optimization tests, and then finally initiated a landscape cutover from development to quality assurance and regression to production. This included a full dress-rehearsal of the production systems cutover one week before go-live.

A simplified diagram showing this high-level process is shown in Figure 8. It is worth noting that during platform migration, the opportunity was taken to fully refresh and synchronize all environments between development and production, providing a higher quality of data for testing and training going forward.

Throughout the test migration and optimization process, the entire migration of all production systems, including all BASIS preparation and post processing, was successfully accomplished in 32 hours. Because of the interconnected relationships between the different SAP NetWeaver software stacks (for example, it is not possible to complete post-processing on Java and SAP NetWeaver Portal systems before ABAP systems have been completed), the following cutover timetable was implemented with two skilled BASIS teams working in shifts and performing all the relevant activities, overlaid by a separate team responsible for ‘export / import / transfer’ monitoring.

Key to the success of any cutover is the preparation of project management timings (see the graphic), and of documentation and reference material that allows for predictable and controlled execution of work.

Migration ‘run books’ were created for each and every system and every phase of the migration (pre-processing, export, transfer of data, import and post processing), all the way to the level of screen-shot by screen-shot walkthroughs and input values for every activity undertaken. In case of emergency, this allowed for junior BASIS staff to complete any unfinished processes.

Migration résumé
All of the vanilla builds and tests were performed, and the successful production systems cutover was accomplished by a team of five skilled BASIS individuals and one SAP operating systems and database migration consultant from EWB Consulting Ltd. in a project that lasted just under six months. The company’s expectations were met to the letter.

Experience with the new environment
At the time of writing, the new consolidated SAP application landscape on IBM Power servers has been in stable production for some months. Compared with the previous distributed setup, the overall performance for both SAP dialog steps and background processing has on average improved by a factor of four.

The systems show an average system utilization of approximately 25 percent post go-live for the SAP environments. The efficient PowerVM virtualization layer contributes to the relatively low overall utilization. Capacity on Demand builds headroom into the solution, and provides about one-third more available space in each individual server. During peak load phases the full, shared resources – with the exception of deactivated CUoD – can be leveraged by individual SAP application processes, which contributes to the overall significant runtime improvements.

The new solution therefore has considerable headroom for growth as well as the capacity to handle sharp workload peaks. Along with the benefits provided by the SAP transaction processing times, this global energy company has achieved its aims of reducing its footprint in both space and energy consumption.

The calculated savings for each of the company’s IT centers related to key infrastructure metrics are significant. The approximate savings achieved by the new IBM POWER platform are 50 percent energy, 40 percent heat dissipation, and better than 60 percent for rack space.

The new systems and operating environment have proved to be very stable. With the benefit of the individually tailored education classes designed to help the customer exploit and manage the new environment as effectively as possible, no unplanned outage has occurred since platform migration was finalized.

IBM has been able to successfully demonstrate technology excellence as well as provide the key skills required to deploy such a complex architecture, and has led the customer to involve IBM in strategic initiatives across other infrastructure projects.

Products and services used

IBM products and services that were used in this case study.

Hardware:
Power 570, Power Systems, Power Systems running AIX 6

Software:
AIX, PowerHA for AIX, PowerHA, PowerVM

Operating system:
AIX

Service:
GTS ITS Server: Server Optimization & Integration Services, GTS ITS Server: Server Product Services for Power Systems, IBM-SAP Alliance

Legal Information

© Copyright IBM Corp. 2011 All Rights Reserved. IBM Deutschland GmbHD-70548 Stuttgartibm.com Produced in Germany. IBM, the IBM logo, ibm.com, i5/OS, DB2, Domino, FlashCopy, Lotus, Notes, POWER, POWER4, POWER5, POWER6, System , and Tivoli are trademarks of International Business Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol (® or ™), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of other IBM trademarks is available on the Web at: http://www.ibm.com/legal/copytrade.shtml UNIX is a registered trademark of The Open Group in the United States and other countries. Linux is a trademark of Linus Torvalds in the United States, other countries, or both. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Other company, product or service names may be trademarks, or service marks of others. This brochure illustrates how IBM customers may be using IBM and/or IBM Business Partner technologies/services. Many factors have contributed to the results and benefits described. IBM does not guarantee comparable results. All information contained herein was provided by the featured customer/s and/or IBM Business Partner/s. IBM does not attest to its accuracy. All customer examples cited represent how some customers have used IBM products and the results they may have achieved. Actual environmental costs and performance characteristics will vary depending on individual customer configurations and conditions. This publication is for general guidance only. Photographs may show design models.