Developing the SAP Data Center : Network Server Preparation

3/12/2013 7:25:34 PM
Optimum Server Configuration Best Practices for SAP

When it comes to server configuration best practices, consistency and standardization are the keys. Consistent server configurations and standard server “builds” or software installations will eliminate a lot of future headaches. Your goals are simple:

  • Minimize variety, which really equates to minimizing variables should you ever need to troubleshoot an issue

  • Allow for rapid server replacement

  • Support your systems management approach

  • Support the lowest total-cost-of-ownership model possible

I cannot say enough about minimizing the different server platforms in your SAP landscape. Two or three specific models of servers should be adequate for even the most complex installations or most cost-conscious customers. The benefits are great—fewer platforms for the SAP TSO to learn to support, less variety in the kind of hardware spare parts that might be stocked onsite, a simpler operating system stack (that is, from a software driver perspective), and so on. I recommend the following, considering these best practices regardless of which server platform is deployed:

  • Only servers specifically certified by the hardware vendor to support SAP should be used.

  • Maintain PCI slot consistency—whenever possible, keep all PCI cards in the same slots on all servers across the landscape. For example, if all servers house a public network card in slot 4, and a back-end network card in slot 6, the SAP TSO support staff will be less inclined to make false assumptions or mistakes later should a network issue arise.

  • Standardize on a particular model of network card, disk controller, host bus adapter, and so on. In this way, not only do you minimize variables from a hardware perspective, you also minimize the variety of software drivers that need to be supported, and the variety of spares that needs to be maintained. In this way, you can even go so far as to swap NICs or HBAs from one server to another, to support troubleshooting without worrying about driver differences, for example. And this approach to standardization simplifies change control as well.

  • Identify any PCI slot constraints, and ensure that these constraints are documented and followed. For example, particular HP servers only support the Remote Insight Board in a particular slot.

  • Disk drives housed internal to each server should contain the operating system and Pagefile or Swap files. We’ll discuss this in more detail later. The point here is that all other data types—database executables, SAP executables, database log and data files, and so on (unless otherwise required) should be housed externally.

  • All internal disk drives should be protected in terms of availability. In some environments, this means attaching these drives to a hardware-based RAID Array controller (a high-availability and high-performing controller capable of withstanding the loss of one or more disk drives, depending on the specific configuration), and mirroring the drives. RAID stands for redundant array of inexpensive disks, and can be implemented via hardware or software (though in the latter case only if the operating system supports software-based RAID). Note that RAID implemented via software can be performed on standard disk controllers—no special controllers are needed beyond those supported by the OS. For the best availability, the controller and any necessary cables should be redundant as well.

  • All external disk drives should be attached to a separate RAID Array controller.

  • If a disk controller does not support mirrored or otherwise protected cache (which is really just RAM that resides on the controller, to speed up reads and writes), or that cache is not backed up by a battery in case of loss of power, the controller should not be used for database or log drives. The reason is as follows. The cache allows writes to be “posted” or acknowledged by the controller, but not actually written to the physical disk drive. In this way, performance is greatly enhanced—the disk controller tells the operating system “I have the data” even when it’s so busy that it does not have the time to actually write the data to the drive. Meanwhile, the operating system is then free to do more work. Later, when the disk subsystem has the time, it commits or writes the data in cache to the physical drives, and the operating system and database are none the wiser. However, if the controller loses power (usually the result of controller failure or losing power to the entire server), all of the writes sitting in the controller’s cache never actually make it to the physical disk, and our database becomes inconsistent or corrupted. A battery backup found on the better controllers gets around this problem, though, by “holding” the data until the server comes back up. At that time, the controller then commits the writes, and again the operating system and database are none the wiser.

  • Standardize on specific firmware revisions for all hardware—servers, disk controllers, disk drives, tape drives, and so on. Like software, firmware tells the hardware how to react or what to do, but it resides on a tiny read-only silicon chip on the hardware component itself. Also like software, firmware is subject to changes, bug-fixes, and so on. I recommend that a customer maintain a specific revision of firmware on each hardware component consistent with the vendor’s SAP Competence Center’s advice, testing planned changes in a Technical Sandbox first. Note that the “latest and greatest” firmware is not necessarily the best, and that a change even at a firmware layer requires the change to be tested and carefully promoted throughout the SAP system landscape.

  • If it ain’t broke, don’t fix it—After a stable platform is assembled and supported by the vendor’s SAP Competence Center, best practices dictate making no changes until forced to. This holds true for hardware components, firmware revisions, software drivers and patches, and so on. Think of it in this way—a lot of work went into assembling a collection of different SAP Solution Stack layers that actually work well together. Stay away from change for the sake of change, and your monthly reports reflecting unplanned downtime numbers will look that much better.

With standardized hardware platforms behind us, let’s embark on the journey to installing and optimizing an operating system for SAP.

Operating System Best Practices for SAP

Although many operating systems are supported for SAP, the following discussion focuses on the most popular OS underpinning new installations over the last three years, the Microsoft Windows family of OSes. In order to install an OS, you need to partition the hard disks upon which the OS will reside. Notice I said hard disks—I highly recommend mirroring the OS partitions or complete drives, such that if one physical drive fails, you can still continue to run from the second drive. With regard to installing the OS, you have two choices:

  • If you are using a RAID Array Controller, you must run an array configuration utility to partition the drives. This readies them to be recognized by an operating system.

  • If a standard SCSI or other controller is used (recommended in cases where software mirroring is warranted), nothing special needs to (or can) be done from a hardware perspective.

Create the OS Partitions and Logical Drives

In the case of a hardware array, create a mirrored pair (also called a RAID 1 set or mirror set). If possible, for maximum availability place the mirrors on drives that reside on separate SCSI busses. This is possible in the case of dual-channel controllers, or with servers where dual SCSI busses reside on the motherboard. In any case, by doing this, an outage can be avoided if a SCSI bus or cable fails. Not only that, but mirroring increases read performance as well, as both SCSI channels and both disk drives can later conduct work simultaneously.

After the disk drives are configured for a RAID set (as appropriate), create a logical drive. This is what will be “seen” by the operating system.


If more than four partitions need to be seen by Windows on a single basic drive, you will need to create additional logical drives. This is because Windows is limited to creating four partitions on the primary bootable drive.

If you have started with a pair of 18GB drives, and assume you need only four or fewer disk partitions to be recognized by Windows, you are done—save the array configuration, and reboot the server to the Windows 2000 installation CD. Install the operating system, selecting to make the bootable partition 4GB or 8GB (or your standard boot drive size), and select the option to format it for NTFS. Finally, after the OS installation, carve up the remaining disks via Windows’s Disk Administrator utility into something just over 4 GB each—I recommend using these additional partitions for the Windows 2000 Pagefiles, discussed next.

Optimal Pagefile Configuration

Windows 2000 is still limited as to how large a physical pagefile can be made—4095 MB. And unless you take advantage of a published and fairly simple registry hack, you can still only place one pagefile on a disk partition (that is, one pagefile of 4095 Megabytes on the E: drive). As of SAP’s most recent Basis releases, total pagefile size should still equal about four times the amount of physical RAM in the server. Thus, a server with 3 GB of physical RAM should be configured with 12 GB worth of pagefiles. SAP further states, though, that a total pagefile exceeding something in the neighborhood of 10 GB offers little to no performance enhancements.

Keep in mind that Microsoft recommends a pagefile on the bootable drive (usually C:) equal to or greater in size than the amount of physical RAM, to support capturing full core dumps should the server succumb to a memory failure. Of course, another simple registry hack allows us to get around this as well. Bottom line, though—if you have the disk space, create the pagefile.

If we return to my server example with 3 GB of RAM, the simplest supported manner of configuring pagefiles would look like this (accomplished by using Control Panel, System):

  • The C: drive should be set up for 3 GB of pagefile.

  • An additional D: drive should be formatted and configured for a 3.5GB pagefile.

  • A final E: drive should be configured for a 3.5GB pagefile, too.

In this way, the server is configured for 10GB of pagefile total. And we have not had to do any registry hacks, nor sacrifice the ability to capture memory dumps. In addition, because we are not completely filling up the drive with a pagefile (we are leaving 500 MB of free space, assuming 4 GB partitions were created), we will avoid those pesky “disk at or near capacity” messages in the Windows Event Viewer. Finally, rather than wasting 2 GB of unnecessary space by building a 12GB pagefile, we instead took advantage of SAP’s concession in pagefile sizing, and created 10 GB total instead.

Another good example of pagefile sizing can be seen in Figure 1; note the partition sizes of just over 5GB each, allowing for maximum-sized pagefiles of 4095MB, with room to spare.

Figure 1. Pagefile sizing should adhere to the best practices noted here.

Other OS Configuration Requirements or Best Practices for SAP

The following configuration changes need to be made or considered prior to installing the database and mySAP component:

  • Work with the SAP Basis team to select an SAP system name, and rename the server with this name. In the past, the server name could not exceed eight characters (releases prior to SAP Basis release 4.6C). Now, the limitation varies depending upon the specific basis release. However, given that SAP management utilities and applications have not all been updated to accept these new limitations, it is still a good idea to limit the name to eight characters until your own specific testing verifies that everything works properly with longer names.

  • Create the admin/installation user (that is, P11adm or something similar) and give it domain administrator (or admin) rights—all SAP Basis installations, updates, and administration will be performed with this user ID.

  • Ensure that all drives were indeed formatted for NTFS (Start Windows Explorer, select each disk, right-click, click Properties, and then select the General tab). Further, format each disk for 64KB blocksizes (or allocation units), and label each appropriately (that is, Pagefile1, Pagefile2, and so on).

  • If not already accomplished, label all remaining disk drive partitions via the Windows 2000 Disk Administrator. For example, label the C: drive OS, the D: drive Pagefile1, the E: drive Pagefile2, the F: drive EXES, the G: drive LOGS, the H: drive DATA1, the I: drive DATA2, and the J: drive DATA3. I also like changing the CD-ROM to drive letter Z: (or another drive letter “out of the way”).

  • Set both the TEMP and TMP environment variables to point to C:\TEMP (by using Control Panel, System).

  • Create the C:\TEMP directory if it does not exist already.

  • Under Network Settings, ensure that the Maximize Throughput for Network Applications option is selected on the File and Printer Sharing tab. This impacts how memory/cache is allocated, and makes a significant performance difference.

  • For each disk partition, grant “everyone” permissions to the root and all subdirectories.

  • Load the SNMP service, in preparation for any systems management agents that will be installed later.

  • Ensure that the appropriate Windows 2000 Service Pack is applied. Note that SAP and Microsoft will oftentimes indicate that a particular version of an OS fix, or patch, or Service Pack is supported. However, I really recommend verifying with your hardware vendor that the specific update in question is recommended and supported on their specific server and disk subsystem platform. Work with the hardware vendor’s SAP Competence Center to verify this information.

  • Ensure that the vendor-specific software kit is approved by the vendor’s SAP Competence Center, and then apply these updates on top of the latest service pack (unless instructed otherwise).

  • Install the systems management agents (that is, Insight Manager, HP Openview, BMC Patrol, and so on per your standard). Refer to the appropriate management agent installation guide for any other details or prerequisites.

  • Set up an alias for SAPTRANSHOST in the HOSTS file—edit C:\WINNT\SYSTEM32\DRIVERS\ETC\hosts and add an entry for SAPTRANSHOST (make it equivalent to the public TCP/IP address, and ensure that the SAP Basis team knows this has been set).

  • Install Internet Explorer (via the SAP Presentation CD).

  • Install the Active Dir Svcs Interface (ADSI), via the SAP Kernel CD (search the CD for ads.exe), if not already installed.

  • Return to Control Panel, System, Advanced, and click the Performance Options button. Verify that performance has been optimized for background services. This setting ensures that SAP processes are given priority over locally logged-on users.

  • Verify via the Windows 2000 Event Viewer that no issues exist from a hardware or OS perspective.

  • Verify via your Systems Management Console (once installed) that no issues exist from a hardware or OS perspective.

  • After the entire configuration process up to this point has been completed, I highly recommend that an automated or unattended installation script be created to easily set up a server that reflects all of the activities completed so far in this list. A disk imaging utility like Ghost is another good way to go. Other options include Microsoft answer files, and HP SmartStart scripts that load HP specific drivers as well as the OS. I suggest leaving out some of the specifics regarding pagefile sizing and partition labeling, so that the script is that much more useful in a generic “SAP server installation” manner. Barring all of these automated approaches, a good old-fashioned checklist will serve the same purpose, as long as it is followed precisely.

  • Finally, to enable remote administrative access to each server, I suggest that a remote control application be tested and deployed. A number of very good solutions exist in the market today—Terminal Services for Windows 2000 is an excellent place to start.

SAP Server Configurations in the Real World

My colleagues and I have seen some pretty amazing SAP server configurations in our day. Think of these as more “Lessons Learned.”

More than once I have seen SAP production systems that are clustered in the name of high availability but forgo basic availability “in the box.” For example, one site chose not to mirror the internal disks located in each SAP cluster node, nor duplicate the requisite controllers and cables. Although this is not absolutely horrifying, it does mean that if a disk drive, controller, or controller cable were to fail, the server would die and the cluster would be forced to fail over to stay up. It has always been my view that it is preferable to never exercise your cluster failover capabilities unless absolutely necessary.

I ran into another cluster issue recently, too. It wouldn’t fail over. As it turned out, it was a one-node cluster.

In another case many years ago, my customer wondered why each server took a performance hit after 15 minutes of uptime. In their eyes, it was definitely a hardware issue. As soon as I walked up to the servers, the real reason was apparent, though—a very nice, and very processor-intensive, screensaver was set to start after 15 minutes of keyboard and mouse inactivity.

One of the biggest problems I see with server configurations regards the use (or misuse) of hosts files. As any network technician knows, the hosts file allows for host name resolution back into an IP address. However, if the contents of the hosts file is incorrect, or the host file itself is absent (that is, perhaps renamed to host, rather than hosts—another real customer issue of mine), and DNS is not being used, name resolution will simply not work. This problem can manifest itself in a “host” of ways—the SAP Basis installation will fail, the server will seem to be unavailable across the network, and so on. Best practices and experience tell us that the hosts file, if used, should reference all SAP servers in the system landscape, and their IP addresses. Each hostname should be listed twice, once in uppercase and once in lowercase letters. If applicable, cluster alias names should also be defined here.

Enough about configuring servers for SAP. Now, let’s move into one of the most challenging SAP Solution Stack layers, the disk subsystem.

Most View
Vivid And Warm Sony Bravia KLD-55W954A
Giants Of The Phone World (Part 1) : Lava IRIS 501
Acer C7 Chromebook - An Inexpensive Chromebook
Windows Server 2008 : Working with Active Directory Accounts - Redirecting Computer Accounts, Redirecting User Accounts
Windows Server 2003 : TCP/IP for AD Transport, Access, and Support (part 3) - Configuring the Windows Time Service, NetBIOS and WINS in an AD Domain
AMD Radeon HD 7970 3GB GHz Edition
Windows Server 2012 : Planning, implementing, and managing Group Policy (part 2) - Group Policy and Active Directory design
Windows 8 : Using other management tools remotely (part 2) - Windows PowerShell
Windows 8 : Managing Application Virtualization and Run Levels (part 1) - Application Access Tokens and Location Virtualization, Application Integrity and Run Levels
Windows 8 : Monitoring, optimizing, and troubleshooting system health and performance (part 2) - App history, Startup, Services
- First look: Apple Watch

- 3 Tips for Maintaining Your Cell Phone Battery (part 1)

- 3 Tips for Maintaining Your Cell Phone Battery (part 2)
- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 1)

- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 2)

- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 3)
Popular Tags
Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 Adobe Indesign Adobe Flash Professional Dreamweaver Adobe Illustrator Adobe After Effects Adobe Photoshop Adobe Fireworks Adobe Flash Catalyst Corel Painter X CorelDRAW X5 CorelDraw 10 QuarkXPress 8 windows Phone 7 windows Phone 8 BlackBerry Android Ipad Iphone iOS
Top 10
3 Tips for Maintaining Your Cell Phone Battery (part 2) - Discharge Smart, Use Smart
3 Tips for Maintaining Your Cell Phone Battery (part 1) - Charge Smart
OPEL MERIVA : Making a grand entrance
FORD MONDEO 2.0 ECOBOOST : Modern Mondeo
BMW 650i COUPE : Sexy retooling of BMW's 6-series
BMW 120d; M135i - Finely tuned
PHP Tutorials : Storing Images in MySQL with PHP (part 2) - Creating the HTML, Inserting the Image into MySQL
PHP Tutorials : Storing Images in MySQL with PHP (part 1) - Why store binary files in MySQL using PHP?
Java Tutorials : Nested For Loop (part 2) - Program to create a Two-Dimensional Array
Java Tutorials : Nested For Loop (part 1)