AWS Cloud Operations Blog

How World Kinect Corporation migrated their Oracle E-Business Suite Applications to AWS

Contributions from Paul Wright, Leader in Database and middleware Services at World Kinect Corporation 

Introduction

With the advancement in maturity and breadth of cloud solutions, an increasing number of enterprises are choosing to embark on migrating their Enterprise Resource Planning (ERP) systems to the cloud. ERP systems sit at the heart of many digital transformation initiatives because of their significant impact on critical business processes such as customer, product, supplier, and employee experiences. Many of these enterprises rely on Amazon Web Services (AWS) cloud to help them automate, extend, and re-imagine these processes so that they can adapt and thrive in today’s evolving economic landscape. AWS has migrated Oracle ERP applications for hundreds of enterprise customers across the globe. By moving existing ERP applications to AWS Cloud, customers not only benefit from availability, flexibility, and security, but additionally benefit from leveraging AWS’ breadth of services to drive innovation and get even more value from their Oracle ERP applications.

In this blog post, we will share how World Kinect Corporation(WK) embarked on their ERP migration journey with AWS. We will walk through how they migrated their Oracle E-Business Suite Applications and dependent systems running on-premises on the Solaris platform to AWS, and specifically highlight the following: (1) their E-Business deployment architecture on AWS, and (2) some of the key architectural, operational, and automation decisions made to address their requirements. The goal of this blog post is to provide you with key considerations to make when preparing to migrate and operate Oracle E-Business Suite workloads on AWS.

World Kinect Corporation (NYSE: WKC), is a leading global energy distribution and management company, offering a broad suite of solutions across the energy product spectrum.

Business Objectives

WK launched an initiative to migrate all workloads to the cloud, choosing AWS because of its breadth of services and global footprint. They successfully migrated 20 out of 22 data centers to AWS in 2 years. The remaining two Data Centers have Oracle E-Business Suite running their core ERP business functions, Oracle SOA applications and dependent custom applications running on Oracle Fusion middleware. It is critical for WK’s Data Center exit strategy to migrate these apps to AWS with minimal impact to business and pave the path for additional modernization.

Dilemma: Approach to get Oracle E-Business Suite to AWS

WK was running an older version of Oracle E-Business Suite 11i with 11g Oracle database on Solaris platform on-premises that was nearing end-of-life. WK intended to migrate their E-Business Suite environment off of the Solaris platform while upgrading their E-Business stack to 12.2 and database to 19c so that they could benefit from the increased functionality advancements, more modern user experience, and enhanced operational efficiency. The big question for WK was whether EBS upgrade, cross-platform conversion, and migration to AWS should be done all together or separated into smaller milestones.  After carefully evaluating which approach would limit interruption to the business and minimize risk, they decided on taking a phased approach to migration. They performed the cross-platform migration to Linux and upgraded the E-Business Suite and database to the latest versions on-premises first, and then migrated the upgraded environment to AWS after 6 months.

Deployment Architecture on AWS

If you need a better understanding of Oracle E-Business Suite components and general deployment guidance we cover that as part of our Oracle E-Business Suite on AWS whitepaper.  In this section, we will go over the architecture and AWS services specific to how WK deployed their Oracle E-Business Suite environment in AWS to meet their business requirements.

As shown in Figure 1, the database tier is leveraging AWS infrastructure core services such as Amazon Elastic Compute Cloud (Amazon EC2), Amazon EBS , Amazon Simple Storage Service (Amazon S3), AWS Backup. For the application tier, Application Load Balancer (ALB) is used for load balancing application traffic, and Amazon EFS is being used for shared APPL_TOP to benefit from the elasticity of the EFS volume to scale as needed. The application and database tiers are deployed across multiple Availability Zones (AZs) for high availability. Oracle Data Guard replication (maximum availability mode) is configured between the primary database in one Availability Zone and a standby database in another Availability Zone. In case the primary database fails, the standby database can be promoted as the primary and the application tier instances will connect to it.

This figure shows how Oracle E-Buisness suite applications can be deployed in AWS

Figure 1. Oracle E-Business Suite Deployment architecture in AWS

As WK migrated these critical revenue generating apps to AWS, developing a highly available, highly performant, and scalable architecture was extremely important. Below we share some of the key points WK considered during their deployment process to meet their environment specific performance, availability and operational requirements.

  • Performance:   To meet the higher memory and bandwidth requirements for Oracle databases, WK considered EC2 x2i instances. These instances offer a choice of 16:1 or 32:1 ratio of memory to vCPU and increased network and EBS bandwidth. For workloads that are I/O latency sensitive and higher I/O requirement, these instances support io2 Block Express volumes. Single io2 Block Express volume provides up to 4,000 MB/s throughput, 256,000 IOPS, 64 TiB storage capacity, and 1,000 IOPS/GB, as well as 99.999% durability and sub-millisecond latency.

Customers also have an option of using Amazon FSx for NetApp ONTAP for the E-Business Suite application and database tiers to take advantage of the fully managed scalability and rich data management capabilities offered.

  • Availability:  For seamless application failover of an E-Business Suite environment in a multi-AZ configuration below are the suggested recommended best practices
    • Configure Oracle E-Business Suite using logical hostname (MOS Note 2567092.1) to ensure seamless transition between primary and secondary databases without needing to reconfigure the application
    • Automate the database failover steps as shown in figure 2, leveraging AWS services to minimize your failover time. Note that Oracle automatic DataGaurd (FSFO) failover capability is not supported as documented in Oracle note 2246690.1

This figure shows the steps involved in automating the Oracle database failover process

Figure 2. Database Failover Automation Process Flow

AWS Services used for Automation:

    1. AWS Step Function state machine is used to orchestrate the complete flow of this switchover automation process.
    2. Program logic is written in shell script which is hosted on AWS EC2 Linux Servers.  AWS Lambda functions written using python invokes the shell script using AWS Systems Manager in respective EC2 instances to perform the required operation.
    3. AWS Systems Manager Parameter store is used to hold metadata information like CDB name, PDB name, EC2 instance names of database, Base path of APPL_TOP, Application servers logical host names, ARN of Application load balancer listener, ARN of the ALB target group and Flag to identify first application node. The information stored in parameter store would be used by the automation process to stop and start services in correct order.
    4. AWS Secrets Manager is used to store the environment credentials.

Benefits Realized: WK leveraged this automation to minimize downtime during planned maintenance activities on the environment.

  • Operational Efficiency: Many ERP customers refresh database environments to ensure that they can perform development, testing, and QA on copies of the most updated, production-like datasets – this is referred to as the cloning process. WK had a requirement to make a copy of their production to a non-production Oracle E-Business Suite environment on a scheduled or as-needed basis. To be able to meet the SLAs for the cloning process and reduce operational overhead, AWS Professional Services designed and developed an automated solution for WK, leveraging native AWS services. The entire cloning process, as depicted in Figure 3, is orchestrated, GUI-driven with AWS step functions, and can be restarted using JSON payload passed between each module/step with the status information of the previous steps.

This figure shows the steps involved in automating the Oracle Ebuisness Suite Cloning process

Figure 3. Cloning Automation process workflow

AWS Services used for Cloning Automation:

    1. A Platform Account is a centralized account from which the clone gets triggered and it can also be scheduled using AWS EventBridge.
    2. Connectivity from the Platform account to source and target accounts are pre-established through cross account AWS IAM access policies.
    3. The clone process is orchestrated through an AWS Step Function state machine, with a JSON string payload passed as input. The payload contains information about source and target accounts.
    4. The AWS S3 bucket (erpclonerepo) is centralized repository to store the clone scripts, logs and instance metadata information.
    5. Enhanced security is provided by storing the passwords in AWS Secrets Manager, with IAM policies being enforced to provide access to secrets. Password reset is done using these secrets in AWS Secrets Manager.
    6. The AWS Step Funtion State Machine calls the sequence of  AWS Lambda functions to perform various activities in the clone process.
    7. Amazon EBS snapshots are used to create a snapshot of the Amazon EBS volumes containing database files on the source. These snapshots are then copied to the target account. The detached volumes and source snapshots will be deleted after cloning to minimize storage costs.
    8. Failure notifications are handled through Amazon SES.

Benefits realized: Through this automation process, WK was able to meet end-to-end cloning SLA of 2 hours, and increase the reliability of the cloning process thru in-built failure and retry mechanisms and automated notifications. The automation accepts parameterized JSON strings as input, which can be adapted for other environments and also can be triggered in parallel to clone multiple environments. With this automation WK was able to clone their E-Business Suite and all the dependent systems without logging into the servers.

Migration Approach

While there are many ways you can migrate an Oracle Database to AWS, WK used the Oracle Data Guard standby option to migrate their 30 TB oracle database and dependent databases ranging from 3-15 TB with minimal downtime. With this option, a physical standby database was created in AWS and kept in sync with on-premise system. When they were ready for cutover, a Data Guard “switchover” was performed and all applications were cutover to use the new database in AWS. To speed up the migration WK increased the AWS Direct Connect and Amazon EC2 instance network bandwidth using a higher EC2 instance profile. Benefiting from the elasticity of AWS, they were able to scale down post migration to optimize costs.

Opening the door for more opportunities

Hosting the Oracle E-Business Suite on AWS enabled WK to scale for peak periods, improve resiliency, and optimize costs.

Conclusion

In this blog post, we shared how WK successfully migrated their business-critical Oracle ERP environments to AWS and was able to exit the last data center resulting in the following business benefits:

  • The new architecture on AWS offers them a flexible, cost optimized D/R environment, allowing them to switch-over for planned/unplanned outages with minimal downtime.
  • Overall system performance is improved since their migration. WK is a volume data company so faster processing means more orders are processed and invoiced faster.

By migrating Oracle ERP systems to the AWS Cloud, ERP customers can take advantage of the ability to scale services in and out that brings faster innovation through the breadth of services that work together and an improved disaster recovery profile.

Author Bio

Malathi Pinnamaneni

Malathi Pinnamaneni is a Senior Migration & Modernization Solutions Architect at AWS, where she helps her customers work backwards from business objectives and provide guidance in how they architect and build resilient, scalable systems in AWS. She leverages her background in databases and middleware technologies along with her passion for developing reusable architecture reference patterns to accelerate customers’ journeys to AWS. Malathi lives in the San Francisco Bay Area, and in her free time enjoys spending time with family and friends.

Sridhar Mahadevan

Sridhar Mahadevan is a Specialist Solutions Architect at AWS specialized in the migration of Oracle ERP application workloads to AWS. He specialises in architecting and right sizing Oracle ERP workloads on AWS. As an automation enthusiast he has developed automations for various Oracle ERP use cases using AWS services. He has a strong background in database platforms and middleware technologies.