Introducing the SAP Data Center

In this chapter, I will discuss in detail the process inherent in building a new data center facility, or transforming your current data center into a foundation capable of supporting a mission-critical enterprise SAP application and its requisite solution stack. The goal is clear—to create a stable and highly available facility for hosting your SAP implementation. I take this process from building out the power, network, and rack infrastructure through installing servers, configuring disk subsystems, and installing server operating systems. In essence, by the time you have completed the activities described in this chapter, the SAP system landscape should be ready for the SAP Basis installations to be performed.

Although you may have already decided on many of the factors that will drive the design and deployment of this facility, including location, hardware and software vendors, and SAP products and components, “availability” should typically represent the single most important consideration driving the data center build-out. Remember, this application and its resident data will ultimately prove critical to your company’s well-being. Should this application and data become unavailable, even for a short period of time, costly and otherwise huge ramifications could result:

• Thousands of users may sit idly by, waiting for the system to come “back.”

• Trucks may stack up in the loading docks, waiting for bills of lading and shipping orders.

• Customers may call in or “click in” looking for status updates on their orders, only to be told to “try again sometime later, the system is down.”

• Manual processes may need to be invoked to keep new orders coming in. And to make it worse, eventually these manual orders will need to be keyed into the system when it again becomes available, further impacting the users’ time to place new orders.

• Reports will be unavailable, impacting decision making from the boardroom down to the assembly line, and everywhere in between.

So, keeping “availability” uppermost in our minds, let’s move on, noting that the data center in some way affects all layers of the SAP Solution Stack. For example:

• At the lowest layer of the stack we find power requirements. I have worked on a number of mySAP.com implementations where as many as 80 new servers and related disk resources are deployed over the course of a year, for example. Such a formidable collection of hardware pulls a considerable amount of amps and volts, not to mention the raw power infrastructure requirements needed to simply keep all of this gear running. An incorrectly architected power infrastructure will bring down an otherwise highly available clustered SAP solution in a heartbeat—all of the high-availability offerings at other layers in the solution are “powerless” without a well-architected Uninterruptible Power Supply (UPS) solution or power distribution system.

• Similarly, cooling requirements must be addressed at one of the lowest layers of the stack. Those same 80 servers I mentioned not only pull a tremendous amount of power, they also generate a considerable quantity of BTUs (British Thermal Units, or units of heat). An inadequate cooling and air handling system can wreak havoc with availability statistics.

• Servers, disk subsystems, network infrastructure, and other SAP-related infrastructure needs to all be neatly racked and cabled. Lack of attention to detail, poor planning, and more can quickly become contributing downtime factors. In more than one case, I have seen racks of servers cabled neatly and in an organized manner, only to have all of this work ripped out after someone finally thought to pull out a server for servicing. Why? Because the cabling did not allow enough “slack” for the servers to be actually pulled out more than a few inches! In other cases, I have seen high availability compromised simply because otherwise redundant pairs of cables were routed through the same cable conduits, and the conduit itself failed or was damaged.

• SAP’s tiered architecture requires forethought in regard to network planning. As you will see later in this chapter, neglecting the impact that a three-tiered architecture can have on public and private network segments can impact not only availability, but also overall performance. In addition, we cannot forget about network firewall security and other network infrastructure considerations that will impact availability when it comes to Internet-facing SAP Web servers, eCommerce/procurement systems, and so on.

• Server infrastructure and design directly impact availability, both “in the box” via single points of failure, and “out of the box” when it comes to higher-layer solution stack matters like failover clustering.

• Your disk subsystem, whether direct-attached SCSI, fibre channel arbitrated loop, switched fabric, or network attached, tends to be the single most important performance factor in my experience, outside of really bad coding. But it is also one of the most easily misunderstood solution components when it comes to high availability.

• Operating system installation, configuration practices, and more can easily impact availability. I will note how and why this seems to be so often overlooked, and help you to conform to best practices in this regard.

As you have just seen, the design and implementation of a company’s specific SAP Solution Stack through a well-planned data center deployment affects availability at all levels of the stack. Single points of failure (SPOFs) abound everywhere. A lone power source, single power distribution unit, nonredundant power supplies, single network segment to a server, single server hosting a database, and more all represent opportunities for downtime. And I have not even begun to discuss the database and SAP application layers!

In the remainder of the chapter, I will take a closer look at each of the availability factors in the bulleted list provided earlier, as well as operational and other processes that will ultimately impact the net availability of your SAP solution to your end-user population.