- Why Is This Important?
- Hardware for SAP: An Introduction
- SAP-Supported Operating Systems
- Database Basics for SAP
- Partnering with Your Infrastructure Providers
- Summary
- Case Study: Hour 4
Hardware for SAP: An Introduction
Hardware, although often an afterthought in an SAP project, is an essential component of an SAP system. Hardware comprises the servers (think “data center computers”), disk storage systems, network gear (such as routers, network switches, and security firewalls), and tape backup units all working together to create the infrastructure or base layer of an SAP system. If any one piece is overlooked or skimped on, it creates a weak link or single point of failure that may cause something down the road as simple as a one-time nagging glitch or as major as a series of significant system outages, costing your company precious dollars. When hardware purchases are addressed late in an implementation, inevitable budget cuts (yes, implementing SAP tends to be more expensive than most companies estimate up front) often restrict purchasing what could have been a robust and highly available system. Advance planning will help you avoid this problem when designing the overall solution.
The major players in the SAP hardware marketplace sell systems that fit all types of solution needs, from small/medium user platforms reflecting commodity solutions and low cost, to larger and highly resilient platforms capable of scaling on the fly to meet the changing or growing needs of thousands of users. Choosing a partner simply based on name recognition is a good place to start, to be sure. However, take care to investigate and compare hardware solutions from competitors that are truly apples-to-apples solutions. A million-dollar commodity hardware solution might support the same workload as a high-end proprietary system costing twice as much, but do they offer the same levels of availability, scalability, and flexibility your business needs to survive month-end closing? By the same token, will saving a few dollars on hardware (or database software, for that matter) require the IT department to spend more money every year on systems management, maintenance activities, and downtime for upgrades and patches?
Server Hardware
We view server hardware as coming in three main initial acquisition “cost” classes or performance categories: small or low, medium, and high (see Figure 4.1). Costs per server can range from a few thousand dollars to several million. Performance can vary as well, depending on the number of CPUs, amount of RAM, internal server architecture factors, support for high-speed disk operations, and much more. Different hardware platforms are developed to support various operating systems and levels of system availability. They differ in terms of configuration flexibility and on-the-fly adaptability too.
Figure 4.1 Servers for SAP come in a variety of sizes and configurations.
Interestingly, a single SAP solution may utilize servers from one, two, or all three categories. For instance, SAP solutions are commonly designed to leverage a high-end server for the database tier, a mid-tier server platform for the SAP central instance or applications servers, and perhaps very inexpensive servers to address web server needs, noncritical bolt-on solutions, and so on. Conversely, other SAP IT departments might choose to put all their SAP components on only a few high-end servers that can be carved up into partitions or virtual machines as necessary. And some small/medium businesses (SMBs) may choose to run SAP solely on low-cost servers (relying on SAP’s built-in application server horizontal scalability to keep them out of trouble should their workload grow). In any case, overall system availability, a comprehensive total cost of ownership analysis (reflecting technology, people, and process costs over time as well as up front), and anticipated future business requirements should drive your hardware platform decision.
Several of the largest and certainly best-known hardware vendors use proprietary CPU chips in their servers and support a proprietary OS as well. IBM’s PowerPC chip running AIX is a good example, as are HP’s end-of-life PA-RISC and more contemporary Itanium2-based IA64 platforms running HP-UX. Be sure to investigate your platform’s ability to host other operating systems as well; this can be beneficial down the road when you need to retire your SAP system and seek to redeploy it internally rather than toss it in the dumpster. HP’s IA64 chips support Windows, Linux, and OpenVMS, for example, whereas Sun’s latest offerings support Solaris, Windows, and Linux.
Clearly the trend of late is around deploying low-cost servers based on commodity CPU chips from Intel and AMD (often referred to generically as “x64” platforms). HP and Dell are the biggest players in this market, though Sun offers a bit of choice here as well. Interestingly, these platforms are growing more and more powerful each year, supplanting some of the bigger server platforms in the process. Commodity server form factors continue to expand and provide IT departments with choice—from dense blades to slim-line “pizza box” designs to more traditional big-box designs. Meanwhile, hardware vendors in this space continue to develop high-availability, virtualization, and other technologies and solutions that help put these servers on more of an equal footing with their proprietary counterparts. In all the excitement and hype surrounding these well-performing upstarts, though, take care not to overlook trade offs. Low cost up front doesn’t always translate to low cost over a system’s lifetime, for example.
When purchasing servers and associated hardware for SAP, consider investing in the high-availability features offered for the platform, even if an additional charge is involved. Most servers offer redundant power supplies, redundant memory, disk array (RAID) controllers capable of running even after a disk drive fails, and support for multiple network interfaces cards (NICs) to avoid failure of a network segment, network switch, or single card. Leveraging these technologies will certainly increase the overall uptime of your SAP solution, typically adding only incremental cost in the process.
Server networks should be configured in a redundant fashion as well. In many IT data centers, the network represents a major—and avoidable—single point of failure. Dual switches and the use of the aforementioned redundant NICs can eliminate or mitigate what otherwise could be a major outage. Of course, these NICs and switches must be properly and professionally installed, cabled, and configured to actually work well; attention to high availability is just as important after the purchase as beforehand.
Disk Subsystem Hardware
Most server hardware vendors also sell disk subsystems, which are essentially enclosures for multiple disk drives used by SAP and other applications to house the application’s database, its installation binaries or executables, and so on.
The most robust and well-performing disk subsystems today are in the form of storage area networks (SANs) and to a lesser extent network-attached storage (NAS) systems. Similar to how servers are marketed, vendors sell low-tier, mid-tier, and high-end SANs and NAS devices. At a minimum, the storage chosen for SAP should support redundant connectivity between the storage and the servers connected to it, so as to avoid a single point of failure. RAID (Redundant Array of Inexpensive Disks) level 0, 1, 5, or 10 should be configured as well to protect against disk failures. As Table 4.1 suggests, different RAID levels provide various combinations of availability, cost, and performance.
Table 4.1. Disk Subsystem RAID Types, Advantages, and Disadvantages
RAID Level |
Method of Availability |
Advantages and Disadvantages |
RAID 0 |
Disk striping |
Spans multiple disks, all of which are available for storage. RAID 0 is great when maximum space is needed, and it provides excellent performance as well. However, no disk redundancy is afforded, and it’s not viable for production systems. |
RAID 1 |
Disk mirroring |
Mirroring provides best-in-class performance and excellent redundancy, although it’s costly (a 500GB database requires a terabyte of raw disk capacity at minimum). |
RAID 5 |
Disk striping with parity |
Stripes data with parity, making for wonderful disk read performance, though to some extent a disk write penalty; excellent redundancy balanced by best-in-class low cost. |
RAID 10 |
Disk mirroring and striping |
Data is both striped and mirrored; best performance and redundancy, although this is the most costly method of providing disk subsystem availability. |
High-end SAN storage typically supports advanced replication technologies, too, which can be useful for disaster recovery purposes among other things. Be sure to look into such capabilities—the ability to copy data between remotely connected SANs or to create “snapshots” of SAP databases on the fly is useful in many different ways, from enabling rapid system backups, to allowing systems to be cloned for offline testing and training, to supporting disaster and business continuity requirements in the wake of a severe data center outage.