The mission of Baldor Electric Company is to be the best marketers, designers and manufacturers—as determined by its customers—of industrial electric motors, power transmission products, drives and generators. From its headquarters in Fort Smith, Arkansas, Baldor supports the sales offices/ warehouses that stock its products worldwide, selling to distributors and original equipment manufacturers in more than 70 countries. Baldor products are available from 50 sales offices/warehouses in North America and 26 offices serving international markets. These products are produced at 26 plants in the U.S., Canada, England, Mexico and China.
By moving workloads to VMs running in IBM System z, and underpinning these workloads with SUSE Linux Enterprise Server (SLES) for System Z, Baldor Electric has achieved significant efficiencies. Working with SUSE, the company has reduced its overall IT costs whilst improving response time, up-time and productivity.
Baldor’s pursuit of its mission was paying off. Because of its high-quality products and responsiveness to customers, by 2004, business demand was increasing. Specifically, Baldor sales grew 8–10% annually, resulting in a commitment to expand existing manufacturing locations and integrate new ones. This growth, however, created some IT issues that, in turn, had an impact on the business.
Many mission-critical applications—including SAP Business Suite—ran on IBM System p running on AIX nodes connected by 1 GB fiber to an IBM System z running DB2. “While response times were okay,” says Eric Breuer, manager, large systems, at Baldor, “We were looking for something faster.” Besides needing better connection speed, Baldor was experiencing rising costs and increasing system complexity. And there were issues relating to ease of upgrading and administration.
Simply adding storage and memory would be expensive and time-consuming. It would also force an increase in IT floor space and power and cooling costs, which needed to be controlled and even reduced. Plus, Baldor couldn’t ensure 24x7 availability to provide quality service to customers and employees and eliminate the risk of business disruption. At the time, outages occurred five-to-eight times a year, costing hundreds of thousands of dollars.
By 2005–2006, it was time for a change. But, could Baldor do more with less, that is, find a solution that could meet growing business demand, accelerate performance and boost availability and, at the same time, reduce costs, shrink the IT footprint and simplify administration?
"We believe SUSE has the best Linux distribution with the best support."
Fortunately, part of the solution was already in-house. Baldor had been using IBM zSeries to run its DB2 environment since the 1990s. Now, by using IBM System z as the foundation for a new solution, the company could count on the high availability and performance necessary to ensure customers had access 100% of the time.
Baldor was also interested in virtualization and in consolidating servers (with z/VM) to cut costs and decrease floor space, power and cooling. So another key feature of System z for Baldor was HiperSockets, an IBM technology for high-speed communications between partitions on a hypervisor that improved performance. In short, expanding use of System z would help reduce costs, by allowing the company to consolidate and leverage existing hardware, as well as help solve speed issues.
Choosing SUSE Linux Enterprise Server for System z
One question remained: what operating system would meet the need for reliability, high availability and faster performance? SLES for System z was the only operating system considered.
“For our proof of concept (POC) in 2006 both IBM and SAP recommended SLES for System z. Based on their strong partnerships with SUSE, SLES for System z is optimized for System z including z/VM, and for SAP,” says Breuer. “We went with the recommendation.”
SLES for System z also had other advantages for Baldor over UNIX, Microsoft Windows and other Linux distributions. To reduce IT complexity and simplify administration, Baldor wanted to standardize on a platform that would run any hardware. SLES was the most interoperable Linux operating system in the marketplace. It also offered the best performance and availability and was SAP-certified, a Baldor requirement.
“In addition,” says Breuer, “running SLES on System z provides the best TCO, especially with IBM’s less expensive Integrated Facility for Linux (IFL), a processor dedicated to Linux workloads, and SUSE’s special volume pricing for IFLs.”
Proof of Concept
For the POC Baldor installed SLES for System z in an LPAR (logical partition), a subset of computer resources virtualized as a separate computer. At first, the Baldor team had concerns about LPAR deployment time and configuring the HiperSockets. However, they had the LPAR with the server and SLES up running in just two days. After that, the team required just a few more days to get that server onto the logon groups in the SAP environment. According to Breuer, “Rather than working according a detailed plan, we had a ‘let’s give it a run’ attitude that allowed us to quickly implement our test solution and tweak it on the fly.”
It worked, and the POC was a success. Baldor moved some batch processing loads over to an LPAR running SLES and saw 36% faster run times. It also pointed some “power users” to this server, who reported better response time. As a result, Baldor chose to go with IBM System z and SLES for System z and opted for extensive SUSE online and classroom training.
Migration, Consolidation, Virtualization
Immediately after the first LPAR implementation, Baldor ordered z/VM—to exploit features like optimized performance, which SLES for System z offers for z/VM—and proceeded to create virtual servers and migrate all its SAP applications to System z with SLES. Baldor’s Linux administrators used a cloning process that allowed them to replicate a Linux instance in 30 minutes. All in all, in just six months they moved all SAP application servers from AIX on System p to SLES on System z.
Running SLES for System z with failover capabilities greatly increased uptime and, with virtualization, allowed Baldor to consolidate its data center from 6,000 down to 900 square feet. Baldor also purchased SLES with Priority Support for SAP for a single point of support— SUSE—for all servers, simplifying service.
Performance also improved. With SAP performance optimized on SLES for System z, Baldor could handle more than one million SAP transactions per day—from internal users and customers—with average response times of less than one second. Using HiperSockets for virtual networking between SLES images also helped to improve speed and availability. “We saw end user response time improve dramatically due to this one item,” says Breuer.
In short, according to Breuer: “SLES for System z has provided a robust implementation for SAP, with unsurpassed reliability.”
The Baldor Environment Today
Based on the success of its huge SAP implementation and the now-extensive SUSE Linux Enterprise knowledge, Baldor migrated and virtualized its entire AIX/p-series environment and many Intel-based workloads to the mainframe and SLES for System z.
Today, 90% of the Baldor workloads running SLES for System z 11 Service Pack 2 are SAP application servers with a mix of ABP and J2EE servers. The rest consists of a mix of web servers and miscellaneous support servers.
Overall, Baldor has two System z machines. One IBM z196 (2817/M32) has activated six Central Processors (CPs), 16 IFLs, three z Integrated Information Processors (zIIPs) and two Internal Coupling Facilities (ICFs). Running on this System z server is the z/VM LPAR for the SAP production environment (with approximately 30 Linux servers that share all 16 IFLs and 300 GB of assigned main storage with a single server using 100GB of that). This System z also has two instances of SLES for System z running in native LPAR mode. One is used as the NFS file server and the other is a production SAP batch server. Baldor employs these two instances so it can run its batch SAP environments on weekends when it may perform its z/VM maintenance.
The second System z machine is an IBM EC12 (2827H43) with Four and two zIIPs, and 2 ICFs. The EC12 runs a SLES in LPAR mode that contains the Central Instance for the Production environment running on the z196. It also runs all the Sandbox/Development/Test workloads under an additional z/VM LPAR that consists of approximately 55 SAP application servers. Since the EC12 was just installed in January 2013, the workload will be rebalanced to even better utilize the systems resources. And all SUSE Linux Enterprise based servers, including others that are web servers, attach to DB2 databases for z/OS via HiperSockets. All DB2 data-bases are using full data sharing between Central Electronic Complexes (CECs).
Also, Baldor takes disaster recovery (DR) seriously, performing DR tests three times per year. The production environment’s SLES for System z instances are restored and connected to the restored DB2. The restores are done from “full volume dumps” of the CKD formatted disks that contain the z/VM DASD farm and the disks that contain the SUSE LPAR Mode servers. They “dump” the volumes while SAP and SLES are running, but at a low-usage time. Baldor also backs up all SLES for System z instances with INNOVATION Data Processing’s FDR/ UPSTREAM. This is primarily for single file restores onsite at the Baldor Data Center, but the FDR backups can be used for DR if the full volume dumps have issues. All of this data (from SLES, DB2 and z/OS) is replicated in real time to the IBM Business Continuity and Resiliency Services in Boulder using an IBM Virtual Tape system with de-duplication—with no physical tape in the data center. The Recover Time Objective for Baldor is six hours for the production SAP environment.
Breuer sums up the Baldor experience: “We believe SUSE has the best Linux distribution with the best support. The reliability, performance and availability of the servers have been ‘first class’. Unlike Baldor’s experience with Windows, the Linux servers never go down, except for maintenance or human error. The platform goes beyond “Five Nines” he says. And the new environment results in considerable time savings for planned downtime.
The experience of working with SUSE and IBM in deploying the entire IBM System z environment running SLES for System z has been and continues to be excellent, with migrations and upgrades going smoothly, and timely call backs and resolutions for all support calls.
The company also keeps up with the latest versions to exploit performance features like dynamic load of additional memory in Service Pack 2. Platform management is straightforward and uncomplicated—requiring only two administrators for z/VM and SLES. The system is also secure—with no virus intrusions or malicious hacking. In Breuer’s words “Security for us is just four words: ‘System z with Linux’—enough said about that.” And scalability is “something we don’t think about any more; if we need a server we have the resources.”
“We have taken our total cost of computing from more than 2% of sales to less than 1%. This has paid for us to stay competitive, take care of users and take care of customers in this 24/7 world,” says Breuer. “That’s why our future plans for SLES for System z on the mainframe include continuing to use the platform for new projects to grow the business and to host more applications from our parent company ABB to allow them to enjoy the high value we provide by running IBM System z with SLES for System z.”