IT@Intel White Paper
Intel Information Technology
Enterprise Resource Planning
March 2010

An ERP Platform Strategy Bas...
IT@Intel White Paper An ERP Platform Strategy Based on Industry-standard Servers

  Contents                           ...
An ERP Platform Strategy Based on Industry-standard Servers           IT@Intel White Paper

  relative to a monolithic ...
IT@Intel White Paper An ERP Platform Strategy Based on Industry-standard Servers

The primary instances and their uses ...
An ERP Platform Strategy Based on Industry-standard Servers                                                               ...
IT@Intel White Paper An ERP Platform Strategy Based on Industry-standard Servers

to optimize hardware costs at the ris...
An ERP Platform Strategy Based on Industry-standard Servers              IT@Intel White Paper

well with production wor...
IT@Intel White Paper An ERP Platform Strategy Based on Industry-standard Servers

Memory scalability                   ...
An ERP Platform Strategy Based on Industry-standard Servers        IT@Intel White Paper

error, and then enables the OS...
IT@Intel White Paper An ERP Platform Strategy Based on Industry-standard Servers

Usages Combining Four-socket         ...
An ERP Platform Strategy Based on Industry-standard Servers                                                               ...
memory capacity, I/O expandability, and                                       failover situations. Their scalability also ...
Upcoming SlideShare
Loading in …5

An ERP Platform Strategy Based on Industry-standard Servers


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

An ERP Platform Strategy Based on Industry-standard Servers

  1. 1. IT@Intel White Paper Intel Information Technology Enterprise Resource Planning March 2010 An ERP Platform Strategy Based on Industry-standard Servers Executive Overview Four-socket servers provide the Many large organizations have a centralized enterprise resource planning (ERP) environment based on proprietary mainframes or RISC-based systems. In performance, memory capacity, contrast, Intel IT has successfully implemented a decentralized ERP environment I/O expandability, and proven that is based on industry-standard servers and supports more than 10,000 technology required to run our active users. We have found that this approach offers several advantages, including lower server acquisition costs and increased flexibility and agility. larger production ERP instances. Four-socket servers perform essential • Larger memory capacity to support large roles within this environment, providing ERP workloads and failover the performance, memory capacity, I/O • I/O expandability expandability, and reliability required to run • Additional reliability, availability, and our larger production ERP instances. These serviceability (RAS) features to support servers also provide enough headroom for mission-critical workloads, such as the new anticipated growth of large production ERP machine check architecture recovery databases over the depreciation cycle of the (MCA recovery) capability server. We use two-socket servers for smaller production instances and a variety of non- We therefore expect to continue to use four- production uses. socket servers to run our most demanding ERP application production instances, as well as Compared with two-socket servers based instances used for benchmarking and disaster on Intel® Xeon® processor 5600 series, four- recovery. Because four-socket servers are well socket servers based on Intel® Xeon® processor suited to act as virtualization hosts, we may 7500 series have key characteristics that also use them in the future to host vitualized enable them to support more demanding Sudip Chahal ERP instances used for development, testing, ERP requirements: Principal Engineer, Intel IT and application support. • Greater performance headroom to support Karl Mailman workload growth, demand spikes, and ERP Infrastructure Architect, Intel IT failover situations
  2. 2. IT@Intel White Paper An ERP Platform Strategy Based on Industry-standard Servers Contents BACKGROUND INTEL’S DECENTRALIZED Executive Overview ............................. 1 There are many large organizations ERP STRATEGY that run their enterprise resource At Intel, the sales and marketing Background ............................................ 2 planning (ERP) applications on a small group was the first to implement number of proprietary mainframes ERP to support its own operations. Intel’s Decentralized ERP Strategy ... 2 or RISC-based systems. This is Other business groups followed Intel IT’s Rationale for primarily because ERP applications similar approaches, and today Intel Decentralized ERP on Industry-standard Servers ............... 2 have historically been marketed and has ERP implementations for finance, implemented as integrated, company- materials management, warehouse ERP Environment Background ......... 3 wide solutions. The perception that management, and other functions. Server Platform Strategy .................... 4 ERP requires a large proprietary Standardization ................................. 4 system remains common today. This approach means that each implementation Four-socket and Two-socket is optimized for the unique needs of the Intel has taken a different approach, Server Positioning Framework ......... 4 group it serves. We use middleware from the eschewing a monolithic, company-wide ERP Four-socket Server Usages ............. 4 ERP supplier to share and synchronize data implementation. Instead, different business Two-socket Server Usages .............. 9 between these implementations. groups implemented ERP individually to Usages Combining Four-socket support their own operations. Each of these and Two-socket Servers: Intel IT’s Rationale for Large Cluster Designs .....................10 decentralized implementations runs on Decentralized ERP on Increasing Use of Virtualization ...11 industry-standard servers located in corporate Industry-standard Servers data centers. This approach offers several Conclusion ............................................11 Decentralized ERP on industry-standard advantages, including lower acquisition costs servers offers some significant advantages Acronyms ..............................................12 and increased flexibility and agility. to Intel, compared with a centralized approach At Intel, these implementations add up to based on large proprietary mainframes or a very large ERP environment. Overall, RISC-based systems. there are about 10,000 active users, and • Lower server acquisition cost. A large, the environment runs on approximately centralized proprietary system has a high 250 servers. acquisition cost—particularly since the Today, ERP suppliers increasingly deliver system must include enough headroom for products as a suite of individual applications growth across all the company’s operations. rather than as a single, integrated solution Acquisition costs for industry-standard as in the past. These applications typically servers are a fraction of this. can run on industry-standard servers. This • Forecasting and flexible scalability. With suggests that industry-standard servers will IT@INTEL continue to be a good fit for ERP. a decentralized design, forecasting and IT@Intel is a resource that enables IT capacity planning can be much simpler professionals, managers, and executives to engage with peers in the Intel IT organization—and with thousands of other industry IT leaders—so you can gain insights into the tools, methods, strategies, and best practices that are proving most successful in addressing today’s tough IT challenges. Visit us today at or contact your local Intel representative if you’d like to learn more. 2
  3. 3. An ERP Platform Strategy Based on Industry-standard Servers IT@Intel White Paper relative to a monolithic design, since availability through clustering. In contrast, their own implementation. This fits Intel’s the needs of only one business unit it is very expensive to add additional large, decentralized budgeting model. have to be comprehended. In contrast, centralized proprietary systems. monolithic designs have to contend ERP Environment Background • Reduced support costs through with the requirements of multiple Two key concepts significantly affect the standardization. Managing applications on business units. way an ERP environment is organized: ERP a large number of decentralized servers can pipelines supporting the path to production • Faster development of new ERP be complex compared with managing a few and ERP components. capabilities. At Intel, each business large multi-processor systems. Conversely, group has its own development, test, and because we use standard servers, we can ERP INSTANCES AND PIPELINES production systems. This enables each group take advantage of the same management to develop new capabilities more quickly and tools, platform engineering, and support For each Intel business group ERP implementation, to release them on an independent schedule. structure used throughout the rest of Intel’s there is a pipeline of ERP application instances. They can inexpensively add servers to create environment. A centralized system used Each instance supports a specific function in test environments that closely resemble only for ERP requires dedicated, specialized the life cycle of ERP releases along the path production environments. management tools and support. from development to production. Additional instances are used for production support and • High availability through clustering. With • Budgeting. With our decentralized disaster recovery, as shown in Figure 1. Each industry-standard servers, it is relatively approach, business groups pay only for instance may be implemented on one or more inexpensive to add systems to achieve high dedicated servers. Finance Quality Production Disaster Development Benchmarking Production Assurance Support Recovery Customer Management Quality Production Disaster Development Benchmarking Production Assurance Support Recovery Pipeline "n" Quality Production Disaster Development Benchmarking Production Assurance Support Recovery Path to Production Figure 1. Examples of enterprise resource planning (ERP) pipelines at Intel. Separate instances support each stage in the path from development to production and support. Each instance is implemented on one or more servers. 3
  4. 4. IT@Intel White Paper An ERP Platform Strategy Based on Industry-standard Servers The primary instances and their uses are: four-socket and two-socket servers. fit for a specific instance. This also helps to We use these reference designs to reduce support costs. • Development. Creating the initial pipeline support most of the ERP instances configuration, populating master data, and in our environment, selecting four- Four-socket and Two-socket creating and unit testing ERP application socket or two-socket designs for Server Positioning Framework modifications. each instance depending on the Our reference designs are based on industry- • Quality assurance. Integrated testing of requirements. standard four-socket and two-socket servers. project changes and system testing to In the past, four-socket servers have been assess the impact across the environment. Standardization the largest-capacity servers available on the Platform standardization is a fundamental • Benchmarking. Performance and market in industry-standard designs and price part of our strategy. The cost and effort of scalability testing prior to production. bands, although industry-standard eight- validating a new platform is significant. It socket designs are becoming available with • Production. Executing production transactions. typically takes about three months to qualify the Intel Xeon processor 7500 series. • Production support. Rapid testing and a new platform and six months if substantial changes to the software stack are introduced The scalability differences between four- validation of fixes to the production at the same time. socket and two-socket platforms vary over environment. time as new generations of each platform are • Disaster recovery. A remote copy of The primary validation steps include identifying released. However, the general distinctions the production instance for executing and testing the server hardware and each remain. Table 1 summarizes the scalability production transactions in the event of feature. We also need to identify and test the differences between current four-socket a disaster. exact stack of drivers, firmware, OS, and third- ERP platforms based on Intel Xeon processor party software required to support our needs. 7500 series and current two-socket platforms ERP COMPONENTS The entire reference design then needs to based on Intel Xeon processor 5600 series. An ERP instance in an ERP pipeline is typically be tested to make sure that it is capable of comprised of multiple components. Primary running production instances and that it can MAPPING ERP INSTANCES TO ERP components include: be supported. We conduct further tests to SERVER PLATFORMS verify correct operation in failover and disaster • Database server. This often requires the The various instances in our ERP pipelines recovery situations, and we verify that the most server resources. require different levels of capacity, performance, server can be monitored in our environment and availability depending on factors such • Primary application server. This application and then make any necessary changes to help as the ERP components they include, the server performs important coordinating ensure manageability. anticipated loading levels, and the usage. A functions, such as load balancing user Because this process is expensive and time- production instance has considerably higher connections and lock management. consuming, there is a significant cost advantage availability and performance requirements • Secondary application server. One or in validating a small set of reference designs than a development system, for example. more application servers within an instance and then using these designs throughout our We determine whether to use four-socket typically execute ERP source code written ERP environment. When selecting a server or two-socket reference designs by mapping in the supplier’s programming language. configuration for a specific ERP instance, it is the requirements of the instance to the much faster and more cost-effective to choose capabilities of each platform. Our current an existing reference design than to qualify a framework for mapping instances to servers SERVER PLATFORM new platform. is shown in Figure 2. STRATEGY It is also typically more cost-effective to We have standardized on a small select a larger server that initially has more Four-socket Server Usages set of server platform reference capacity than required, rather than qualify a Intel IT has standardized on four-socket designs based on industry-standard new server in an attempt to find the perfect servers for larger ERP production instances 4
  5. 5. An ERP Platform Strategy Based on Industry-standard Servers IT@Intel White Paper Table 1. Comparison of Current Two-socket and Four-socket Enterprise Resource Planning (ERP) Platforms Two-socket Server Based on Four-socket Server Based on Benefits of Four-socket Servers over Intel® Xeon® Processor 5600 Series Intel® Xeon® Processor 7500 Series Two-socket Servers1 Number of cores 8 to 12 16 to 32 Performance scaling: Up to 2.3x Number of threads 16 to 24 32 to 64 I/O slots 4 to 6 8 to 10 Greater I/O expandability: Typically 2x Memory slots Up to 18 Up to 64 Greater memory capacity: Up to 3.55x Maximum memory capacity with 72 GB 256 GB 4-GB DIMMs Reliability features Standard Advanced features including machine check Greater uptime for mission-critical workloads architecture recovery (MCA recovery) 1 Scalability differences depend on specific server configurations. and supporting database environments. This is because four-socket servers provide enough headroom for anticipated growth of Current Server Platform Positioning Framework a large production database and instance Four-socket Data Warehousing Candidates Larger Application Workloads over the depreciation cycle of a server. We Two-socket also use four-socket servers for benchmark Finance Candidates and disaster recovery instances because Customer Management they need to reflect production, and we are Inventory Management investigating their use as virtualization hosts. Purchasing LARGER PRODUCTION ERP INSTANCES Planning and Forecasting The ERP production environment is mission Mid-range Workloads Middleware critical; maximizing application availability is End User Portal paramount. The need to minimize scheduled Monitoring n/a n/a n/a and unscheduled downtimes greatly outweighs the requirement to optimize Environment Management n/a n/a n/a hardware acquisition costs. An additional Production Benchmarking Disaster Recovery Production Support Quality Assurance Development n/a - not applicable important factor is that the cost of industry- standard server platforms represents only a few percent of the total project cost when development costs, software costs, and other expenses are tallied. Larger, More Demanding Instances Smaller Instances Therefore, allowing significant headroom for unanticipated needs—at a very modest overall impact on total cost of ownership (TCO)—is Figure 2. Current server positioning framework for Intel’s enterprise resource planning (ERP) environment. almost always greatly preferable to trying 5
  6. 6. IT@Intel White Paper An ERP Platform Strategy Based on Industry-standard Servers to optimize hardware costs at the risk of availability solution for critical ERP components supported by both servers and continue to impacting application availability. with just two servers, as shown in Figure 3. deliver good performance while doing so. In normal operations, the database and the In general, downtimes must be scheduled primary and secondary application server Performance far in advance and typically entail complex software components are distributed across In general, the performance scalability and negotiations with Intel business groups. the two physical servers for performance. In headroom of a given server platform is The data center operations team does not failover mode, all these components run on a function of the overall platform design have the option of incurring unscheduled the single surviving server. encompassing the processor, cache, memory, downtime by bringing down the application and I/O subsystems as a whole. in order to resize the server to cope with DETERMINING WHETHER PRODUCTION increases in demand. Testing performance with actual workloads. INSTANCES REQUIRE FOUR-SOCKET While published benchmark results can convey It is much better to modestly overprovision SERVERS some information on the performance and upfront than to go back to the business We determine whether a production instance scaling potential of a given server platform, group to request scheduled downtimes for is large enough to require a four-socket it is critical to measure performance using hardware upgrades. For example, it would server by comparing the anticipated peak actual mission-critical ERP production simply not do to delay quarter-end financial workload requirements with the capacity of a application workloads. processing because the underlying hardware cluster based on four-socket and two-socket platform had not originally been sized with reference designs. Published benchmark data can also be a good adequate headroom for “unanticipated” starting point for comparing the performance If peak requirements of an ERP database workload growth. scaling potential of different server platforms— workload are expected to exceed 40 percent especially platforms with similar designs, such Therefore, a production ERP server platform of the performance, memory, or I/O resources as two four-socket servers—but it does not must include enough performance headroom, of a cluster based on two-socket servers, provide enough information to make platform memory capacity, and I/O scalability to we standardize on a two-node four-socket selection and configuration decisions. accommodate increases in the workload. server cluster. This is because in a failover situation, the surviving server must be able to In particular, extrapolations from benchmark Our standard configuration for supporting run the entire workload that was previously results obtained on server platforms with larger production instances is a cluster of widely differing expandability and scalability two four-socket servers. This provides a high- attributes, for example two-socket and four-socket servers, to production workload performance projections is fraught with many risks and must be approached with great care Primary Java* Application Primary Java Application for a number of reasons. Application Server Server 1 Application Server Server 1 First, the benchmark workload cache, memory, Secondary Java Application Secondary Java Application and I/O resource consumption profile may Application Server Server 2 Application Server Server 2 differ materially from that of the production Application Service Application Service workload. For example, the benchmark workload may fit comfortably in the memory Java Service Java Service configuration of a two-socket server, while the production workload may require the Database Server Database Server much greater memory capacity of a four- socket server to handle peaks in demand and/ Location of component during normal operation Location of component during failover or failover modes. In these situations, the benchmark results are unlikely to correlate Figure 3. Standard clustered production instance. 6
  7. 7. An ERP Platform Strategy Based on Industry-standard Servers IT@Intel White Paper well with production workload performance infrastructure may feature high-speed fabric • Uncertainty about workload spikes. results. The reason is that attempting to interconnects and high-end storage subsystems Long-term workload averages may not run the production workload in a memory- that may not be available in the targeted reflect brief periodic spikes in demand. constrained two-socket configuration may enterprise infrastructure—and the infrastructure To support business requirements, the sustain severe paging-related performance may be limited by the presence of significant ERP platform must maintain a responsive slowdowns that were not a factor in the legacy elements. It is entirely possible that a environment under all loading levels published benchmark results due to the much benchmark configuration with more mainstream including workload spikes, avoiding smaller memory footprint of the benchmark (lower capacity, speed) memory and I/O response time service-level agreement workload. Similar considerations can apply to subsystems and infrastructure may have (SLA) excursions if at all possible. I/O scaling requirements. For example, if the resulted in significantly lower performance • Uncertainty in forecasting future benchmark workload I/O profile is significantly than the published benchmark metrics. workload placement decisions. In some less intensive than the production workload Factors influencing performance situations it may be desirable—for cost, I/O profile, the applicability of the benchmark headroom requirements. Four-socket performance, or architecture reasons—to land comparisons to the production environment servers currently have up to four eight-core new applications on existing servers rather will be limited. processors; as a result, they typically have than installing new servers. The headroom Second, there may be significant configuration 1.9x to 2.3x the performance headroom provided by four-socket servers can give us differences between benchmark and planned compared with two-socket servers available additional operational flexibility to do this. production configurations, both at the at the time of publication. This headroom can • Failover mode. When failover occurs, platform level and at an infrastructure be very important for the following reasons: all critical ERP components move to the level. It is very possible, even likely, that • Uncertainty about future workload surviving node in the cluster. The surviving published benchmark results are based on volumes. Despite the use of sophisticated node must still continue to deliver excellent very expensive, high-density RAM subsystems benchmarking and planning discipline responsiveness while maintaining sufficient and I/O subsystems—configurations that to forecast growth in workload average headroom for unanticipated workload spikes. would not be practical or cost-effective for volumes, there can be considerable implementing a large-scale ERP pipeline. Some of these concepts are shown in Figure 4. differences between the expected average Likewise, the supporting benchmark volumes and what we actually observe. 100% Maximum Target Utilization Percentage of Total Server Capacity Worst-case Headroom for 80 Unexpected Workload Spikes 60 40 20 0 Normal Operations Normal Operations Failover Mode Average Workload Peak Workload Peak Workload Figure 4. Performance headroom planning. 7
  8. 8. IT@Intel White Paper An ERP Platform Strategy Based on Industry-standard Servers Memory scalability more users, back up larger databases, or a hardware problem on the multi-port card ERP workloads can have demanding peak support more applications. or the slot itself can leave the server with memory requirements. The much greater no LAN or SAN connectivity. Additionally, Our current four-socket designs typically memory capacity of four-socket servers— a design with multi-port LAN and SAN have eight slots, compared with four in our typically more than 3.5x the capacity of connections may not scale as effectively two-socket reference designs. This enables two-socket servers at the time of writing— because the ports share common hardware us to add network interface cards (NICs) is often a decisive factor in server resources and because drivers may limit and host bus adapters (HBAs) to increase selection. Considerations include: performance. performance and redundancy; for example, • Large ERP workloads. Total memory we include two dual-port NICs in a typical • Platform standardization. The presence requirements during normal operation may production ERP server. of additional connectivity slots allows an be too high to be safely accommodated architect to simply add standard, proven Without an adequate number of I/O expansion within the smaller RAM capacity of a two- building blocks such as pre-qualified NICs slots, platform architects may need to make socket server. or HBAs to the platform as necessitated undesirable trade-offs between performance, by demand signals. Adding non-standard • Failover. Even with smaller ERP workloads, scalability, redundancy, and standardization. solutions such as multi-port HBAs to solve memory requirements may be too high in a These interrelated considerations include: a specific problem can create substantial failover situation to be safely accommodated • Data center LAN and SAN connectivity additional cost because of the need to on a single two-socket server. constraints. A straightforward upgrade qualify and support each new component. • Memory redundancy. A four-socket to respond to growing I/O demand would server makes the use of memory be to swap out existing LAN or SAN cards Reliability, availability, and redundancy schemes much more feasible. with higher speed NICs or HBAs. However, serviceability Memory redundancy may become more if the data center LAN infrastructure In the ERP production environment, high desirable with increasing memory sizes cannot support 10 gigabit Ethernet (GbE), application availability is paramount. due to the need to minimize soft-error then swapping out existing 1-GbE NICs To maximize uptime of mission-critical rates. Using memory redundancy means for 10-GbE NICs will not solve server I/O applications, four-socket servers include that twice as much physical memory may bottlenecks. Similarly, if the data center a range of RAS features that are not be needed to achieve the same effective SAN fabric is limited to 2 GB per second, currently available in two-socket servers. memory capacity. upgrading the HBA to 4 GB per second will For example, four-socket servers based on not help performance. Intel Xeon processor 7500 series include more I/O scalability • Limitations of multi-port NICS and than 20 new RAS features. These include Four-socket servers typically have HBAs. Our reference designs use NICs and MCA recovery, available for the first time in approximately twice as many Peripheral HBAs with no more than two ports each. servers based on Intel Xeon processors. Component Interconnect Express* (PCIe) To increase the network I/O capacity of expansion slots as two-socket servers, With MCA recovery, the hardware works with four-socket servers, we add more NICs. An providing the ability to support ERP the OS or virtual machine monitor (VMM) alternative way to increase I/O capacity in workloads with much more demanding I/O to increase system availability by allowing a server with a limited number of slots is requirements. Even if workloads do not servers to recover from uncorrectable to use quad-port NICs and HBAs. However, require this I/O scalability immediately, memory errors that would otherwise cause this creates a single point of failure: With they may need it in the future to host a system crash. MCA recovery detects the only one multi-port NIC or HBA per server, 8
  9. 9. An ERP Platform Strategy Based on Industry-standard Servers IT@Intel White Paper error, and then enables the OS to determine • Memory capacity. Non-production ERP are the workhorses for a vast number of the best course of action. This can keep VMs have large RAM requirements— mainstream uses. the server running when the error affects a typically 8 GB or more per VM. Four-socket Newer technologies are often incorporated non-critical process, or does not affect any servers, with their large memory capacity, into two-socket server designs first, where processes. For example, if the error affects can accommodate this. they prove themselves in less-demanding a non-critical process, the OS may terminate • MCA recovery. MCA recovery, which allows scenarios before making their way into four- and restart the process while keeping the servers to recover from uncorrectable socket server designs where there is less server running. memory errors, is particularly valuable in room for relatively unproven technologies a virtualized environment where multiple or concepts. Conversely, four-socket servers VIRTUALIZATION HOSTS applications are consolidated into VMs on tend to rely on more mature and proven Beyond existing deployments, we are each server. When the hardware detects technologies and to have longer design and investigating the possibility of virtualizing an uncorrectable memory error, MCA validation cycles. many non-production ERP instances. Our recovery enables the VMM to determine Within Intel’s ERP environment, two-socket goals are to reduce cost and increase agility in the best course of action. For example, servers are used predominantly in cases servicing requests to host new ERP instances. the VMM may shut down and restart the that do not require the scalability of a large We are investigating the use of four-socket VM directly affected by the memory error, production instance: smaller production servers for this due to a number of factors: while all other VMs on the server are able instances and a range of non-production to continue to run unaffected. • Large number of cores and threads. uses such as development, production A four-socket platform based on Intel • I/O slots. Virtualization hosts have support, and QA. They often run the same Xeon processor 7500 series has up demanding I/O requirements. Our current ERP components as four-socket servers, but to 2.7x as many processor cores and virtualization host platform reference design because they have fewer resources, they available threads as current two-socket includes seven ports for LAN connectivity. provide less scalability, support fewer users, servers based on Intel Xeon processor These are used for functions including or support a less stringent SLA in terms of 5600 series. This confers a considerable production networks, live migration, performance or system availability. Production advantage in serving as a virtualization management, and backup and restore. The instances may run on a two-node cluster, host (see sidebar for more detail). We design also includes two SAN connectivity while many non-production instances are expect to configure ERP virtual machines functions. The eight slots typically available supported using an “all-in-one” configuration, (VMs) with two to four virtual CPUs each in four-socket platforms translate into much as shown in Figure 5. (or in the future, eight virtual CPUs in greater I/O headroom and flexibility. In the some cases), depending on the virtualized future, it is possible that high performance Secondary Application Server workload. Given the importance of ERP requirements may necessitate dedicating applications and the need to help ensure NICs or other I/O devices to a given VM. The Primary Application Server responsiveness, we are evaluating the additional I/O slots in four-socket servers Secondary Application Server possibility of a balanced approach in which make them well suited to support this need. the number of virtual CPUs does not Database Server exceed the number of physical cores in the Two-socket Server Usages server. In a balanced configuration, we can While four-socket servers are targeted for Figure 5. All-in-one non-production enterprise run 2.7x as many VMs on a four-socket higher-end applications and more mission- resource planning (ERP) instance running on a server as we can on a two-socket server. critical functions, two-socket servers two-socket server. 9
  10. 10. IT@Intel White Paper An ERP Platform Strategy Based on Industry-standard Servers Usages Combining Four-socket existing large instance hosted on a clustered capacity using industry-standard servers to and Two-socket Servers: Large pair of four-socket servers, as shown in scale out application processing as opposed Cluster Designs Figure 6. Application servers that are part of to qualifying and standardizing larger Two-socket servers running additional a large ERP instance can become capacity proprietary servers. application server modules can be used to constrained due to workload growth or the The scale-out design is also very important add incremental scale-out capacity to an addition of uses or users. We add incremental when the business processes include batch Core Count Considerations in Virtualization Hosts  Virtualization software emulates hardware as virtual machines (VMs) that share the resources belonging to the underlying virtualization host server, providing a way to efficiently run multiple OSs and applications concurrently on the same physical server. Depending on the processing requirements of an application, the VM hosting the application may be configured with one or more virtual CPUs. In order to closely emulate the behavior of a multi-processor computer, the virtualization software typically assigns each virtual CPU to a physical core on the host server, or to a thread in the case of hosts that support hyper-threading. On a virtualization host running multiple VMs, virtual CPU oversubscription occurs when the number of virtual CPUs required to concurrently run all the VMs exceeds the number of physical cores (or threads) available. In these oversubscribed environments, VMs take turns sharing the available cores. The scheduling and associated context-switching overhead, such as saving and restoring VM states and flushing and refilling caches, can sometimes result in performance degradation. The performance impact may differ depending on workload characteristics. In a significantly oversubscribed environment, workloads that are easier for the virtual machine monitor (VMM) to schedule because they are hosted in VMs requiring only a few CPUs, or that are more compute-intensive and therefore can more efficiently use the CPU time allocated to them, may be less impacted than workloads requiring a large number of virtual CPUs. The decision about how many VMs to run on a virtualization host may depend on whether the priority is to maximize consolidation ratios or to achieve predictable high performance and minimize performance-related variability. Oversubscription allows us to consolidate more virtualized workloads onto a single virtualization host, improving overall resource utilization. However, as we add more VMs and oversubscribe the available cores (or threads), there may be an increasing possibility of performance excursions that are intermittent and difficult to reproduce. In contrast, a balanced configuration in which the number of requested virtual CPUs equals the number of physical cores (or threads) available on the platform may help deliver relatively more predictable performance for all VMs. For mission-critical applications where predictable performance is critical, such as ERP environments, IT organizations may choose the balanced approach. In these situations, the substantially greater core count of four-socket servers provides a key advantage, because it allows us to run many more VMs per host without oversubscription. For example, a VM might be assigned two virtual CPUs. A two-socket server based on Intel® Xeon® processor 5600 series, with six cores per processor, has a total of 12 cores and 24 threads and can host twelve VMs without oversubscription. A four-socket server based on the Intel® Xeon® processor 7500 series, with eight cores per processor, has a total of 32 cores and 64 threads and can host 32 VMs without oversubscription—about 2.7x times as many as on the two-socket server. This scalability may be an important factor favoring the selection of four-socket servers as virtualization hosts. To read more about Intel IT and virtualization, go to 10
  11. 11. An ERP Platform Strategy Based on Industry-standard Servers IT@Intel White Paper processing, programs that interface between systems, or parallel processing of order documents. This creates a place to isolate Primary Java* Application Primary Java Application Application Server Server 1 Application Server Server 1 the impact of these very resource-intensive workloads from the rest of the system Secondary Java Application Secondary Java Application usage. ERP software with support for log Application Server Server 2 Application Server Server 2 on workload balancing and other workload Application Service Application Service directing schemes makes this isolation scheme possible. Java Service Java Service If the database server becomes a bottleneck, Database Server Database Server then the instance can be repartitioned by moving some of the application servers off Secondary Application Server the four-socket server running the database service to an additional two-socket host. Secondary Application Server Secondary Application Server Increasing Use of Virtualization Location of component during normal operation Over time, we expect steady adoption Location of component during failover of virtualization in the ERP environment, starting with the lowest-risk instances and Figure 6. Two-socket servers running additional application server modules can be used to add incremental progressing to more critical server roles scale-out capacity to an existing large instance hosted on a clustered pair of four-socket servers. as virtualization delivers proven stability, reliability, and performance. The possible changes to our future server Possible Future Server Platform Positioning Framework platform positioning framework due to Four-socket Data Warehousing Physical Server Larger Application Workloads virtualization are shown in Figure 7. In this Candidates Finance scenario, many smaller non-production ERP Four-socket Virtual Machine instances are virtualized and run on four- Customer Management Candidates socket virtualization hosts. Large production Inventory Management Two-socket instances continue to run on four-socket Candidates Purchasing servers as they do today, because they Planning and Forecasting require the additional performance, memory, Over time, two-socket servers may and I/O scalability that these servers provide. Mid-range Workloads Middleware gradually redefine mid-range workloads upwards End User Portal Monitoring n/a n/a n/a CONCLUSION Environment Management n/a n/a n/a Intel’s ERP strategy has enabled Intel Production Benchmarking Disaster Recovery Production Support Quality Assurance Development n/a - not applicable IT to effectively support more than 10,000 active users with industry- standard servers. Four-socket servers play an essential role in Larger, More Demanding Instances Smaller Instances this strategy. They provide the performance, Figure 7. Possible future server positioning framework for Intel’s enterprise resource planning (ERP) environment. 11
  12. 12. memory capacity, I/O expandability, and failover situations. Their scalability also makes proven technology required to run our four-socket servers well suited to act as ACRONYMS larger production ERP instances. They also virtualization hosts, and we are investigating ERP enterprise resource have the headroom to continue delivering using them as hosts for virtualized non- planning good performance while accommodating production ERP instances. GbE gigabit Ethernet workload growth, spikes in demand, and HBA host bus adapter MCA recovery machine check architecture recovery For more straight talk on current topics from Intel’s IT leaders, NIC network interface card visit PCIe Peripheral Component Interconnect Express RAS reliability, availability, and serviceability SLA service-level agreement TCO total cost of ownership VM virtual machine VMM virtual machine monitor This paper is for informational purposes only. THIS DOCUMENT IS Intel, the Intel logo, and Xeon are trademarks of Intel Corporation in the U.S. PROVIDED “AS IS” WITH NO WARRANTIES WHATSOEVER, INCLUDING and other countries. ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS * Other names and brands may be claimed as the property of others. FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION OR SAMPLE. Intel Copyright © 2010 Intel Corporation. All rights reserved. disclaims all liability, including liability for infringement of any proprietary rights, relating to use of information in this specification. No license, express Printed in USA Please Recycle or implied, by estoppel or otherwise, to any intellectual property rights is 0310/KAR/KC/PDF 322692-001US granted herein.