Infor’s journey to fully managed SMB storage

Storage is a strategic component of the enterprise business cloud software products we build at Infor. Scaling up storage and integrating a storage solution with existing applications can be challenging. At Infor, we searched for shared SMB file storage in the cloud to reduce operational management, increase scalability, and lower costs. These factors, critical to any business, were key to why we jumped at the opportunity to migrate our shared storage to fully managed Amazon FSx for Windows File Server (Amazon FSx) from a third-party hosted solution.

In this blog post, I highlight the migration path of one of our most successful Enterprise Resource Planning (ERP) commercial software offerings, called Infor LN, to the AWS Cloud. I also walk through performance tests that helped us compare our legacy storage solution’s performance to the performance of Amazon FSx before our migration.

Where we started

Infor automates critical processes for industries including healthcare, manufacturing, fashion, wholesale distribution, hospitality, retail, and public sector. I started at Infor as a Systems Administrator on the Commercial Cloud Database Team. At that time, for our Infor LN application, we were in the early development stages of automating the deployment of SQL Always on Availability Group Clusters on AWS. Part of that development also included Windows Server Failover Clustering (WSFC), with a SQL Server 2012 Always on Availability Group (AoAG). With high availability and auto healing deployments being key components of our infrastructure design, shared storage was a critical need.

At the time, there were limited options, consisting of AWS Marketplace-based solutions, all of which we extensively tested, in search of high performance and a robust file system. All were acceptable but required dedicated resources to manage and maintain. We settled on a third-party cloud storage solution that not only outperformed the alternatives we tested, but also provided top tier service and support.

The third-party solution we chose resided in nearby data centers connected to AWS Regions via AWS Direct Connect. These 10-Gigabit connections provided the performance and reliability we needed, in addition to adding the versatility of backing up to Amazon S3, container services, and a robust API for management.

The following diagram displays the major components of our Infor LN application. We deploy the application into three AWS Availability Zones.

• Public Elastic Load Balancing (ELB) for customer access
• The UI servers are the web server component for the user interface
• The online transaction processing (OLTP) servers handle the online transactional processing
• The Batch Processing servers schedule the LN job executions
• Third-party storage network connection using AWS Direct Connect
• SQL Server relational databases for data storage
• Private Elastic Load Balancing for internal communication

Infor LN ERP application using a third-party hosted storage solution

Challenges with third-party hosted storage

Our shared storage needs grew exponentially, so scalability and performance were paramount. Scaling the third-party storage solution required direct contact with the vendor and was time consuming.  Additionally, the third-party cloud storage provided CIFS, NFS, and iSCSi file shares for many different applications that had very different storage and performance requirements. One application could easily affect another’s performance, and procuring new, shared storage required us to plan to handle the increasing load. This planning process involved participants from several teams taking many work hours and careful coordination. Management of this storage took additional resources to automate monitoring and maintenance tasks. Since the third-party storage solution was outside of AWS, it did not integrate with the AWS Cloud.

How did the Amazon FSx file system measure up?

In 2018, no one was more excited than I was when AWS announced a new fully managed SMB file service: Amazon FSx for Windows File Server. Over time, Amazon FSx expanded region-by-region across the globe, and met our high availability standards with support for multiple Availability Zones. We quickly realized the potential benefits of this fully managed, highly reliable, and scalable file system that deployed in minutes.

Before migrating our storage to Amazon FSx, we tested, benchmarked, and analyzed performance to ensure that the file system met all of our requirements. The following includes our Performance and Benchmark Center Team test results comparing two shared storage solutions: the third-party hosted storage and FSx for Windows File Server. Our goal was to measure the performance and determine the stability of shared file systems for our LN application.

There were nine benchmarks used for this testing, and I highlight three of them in this post:

• Version Release Customer Code copy (large directory)
• Company export
• Concurrent file open test

Version Release Customer Code (VRC) copy

The following graph shows a VRC copy, a software component directory of LN. A software directory contains many files: objects, forms, menus, etc. I use this to simulate activities taking place in the LN maintenance windows.

Copying 2500 files took 30 seconds using Amazon FSx, versus 143 seconds using the third-party storage solution, which is an improvement of 4.76x.

Company export

The following graph shows the duration of the company export. A company export is an LN feature to create a backup of a customer dataset. It creates many CSV files on shared storage. Our customers use this feature a lot.

In this example, we exported 9.4 GB (4450 files). Delivering customers a copy of their current company data results in significant time savings, in the range of 4.6-7.9x faster with Amazon FSx.

Concurrent file open test

The following graph shows a concurrent file open test.

The graph above shows p90 response time for concurrent open file performance tests using 10, 50 and 100 threads showing 8x performance advantage for Amazon FSx. Overall, based on all of our testing, Amazon FSx is about 80% faster than the our previous hosted solution.

Amazon FSx passed the performance and reliability test with flying colors. So, what is the most efficient way to migrate our data from third-party hosted storage to Amazon FSx and stay within our maintenance window?

Migrating third-party hosted storage to Amazon FSx

With global availability secured for Amazon FSx, we proceeded with migrating all applications that used shared storage to the service. The transition from the third-party hosted storage to Amazon FSx was an easy process. We used multiple instances to synchronize our data the week prior to the cutover. After doing a final sync at the start of the maintenance window, our application maintenance finished in record time. The deployment of Amazon FSx was simple using AWS CloudFormation templates, and Amazon CloudWatch made it easy to handle monitoring. I outline the migration steps in the following subsection.

Comprehensive migration plan to Amazon FSx

Our LN Operations Team developed a comprehensive migration plan.

For each LN farm, we executed the following steps:

1. Create an Amazon FSx file system using in-house automation tools.
2. Make an initial copy of the third-party share to the Amazon FSx file system using a master instance. Validate this copy was successful.
3. Every day until the maintenance window, synchronize the differences from third-party storage to the Amazon FSx file system using “worker instances” in parallel.
4. A few hours before the start of the maintenance window:
   • Tear down the existing management instance, the utility server used for application and tools upgrades.
   • Change the Storage parameter to refer to the Amazon FSx file system.
   • Deploy the new management instance.
   • Validate that the Amazon FSx file system can be accessed from the management instance.
   • Increase Auto Scaling group for “Worker instances” to 4 to handle the last sync action.
5. At start of the maintenance window:
   • Tear down all LN instances (except for the Amazon FSx primary instance and management instance).
   • Sync last differences from third-party hosted storage to Amazon FSx file system.
   • Validate no errors occurred.
6. Continue with normal maintenance window procedures:
   • Update all LN instances (except for the Amazon FSx primary instance and management instance).
   • Start tools update on management instance.
   • Finish maintenance.

Conclusion

Our shared storage journey is now complete. With Amazon FSx securely storing our data on the AWS Cloud, data management headaches and the high storage costs associated with third-party storage are a distant memory. After moving about 11 TB of data in 3 Regions, we were able to decommission 5 storage arrays and save over 6 hours a month of management time. All in all, we reduced our storage costs by about 50%. With less time and money spent on data storage, we can focus on our core business – delivering mission-critical enterprise applications for our customers – without having to worry about pre-provisioning storage as we scale.

Thanks for reading about Infor’s migration journey to fully managed Amazon FSx for Windows File Server. If you are interested in learning more about how Infor is building on AWS to drive innovation, check out the case studies we have completed with AWS. Please leave a comment if you have any questions, and I look forward to sharing more storage migration learnings from our team in the future.