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.
Note
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.
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.
|
