- 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
This chapter is from the book
This chapter is from the book
This chapter is from the book
SAP-Supported Operating Systems
An operating system (OS) is software that allows applications to interface with a computer or server. The OS is the middleman, making a system’s hardware accessible to an application sitting atop the OS while providing basic services to applications (such as file sharing, support for network connections, and so on) in the process. Operating systems such as Microsoft Windows Server, Red Hat and SUSE Linux, and the many popular UNIX variants (HP-UX, AIX, and Solaris) are common in today’s SAP environments. Even the occasional IBM iSeries or AS/400 (running the OS400 operating system) or mainframe (running z/OS) can be found supporting SAP today as well.
Figuring out which is the best for your solution can be a daunting task, however. More and more, the OS playing field is being leveled. Robust 64-bit technology in the commodity server market has many SAP shops rethinking their strategy. When choosing an OS, it all comes down to relationship, confidence, supportability, and particularly your in-house IT skill sets and personal biases. To this end, always take care to factor in your current in-house skill sets, comfort levels, and ability to be “retooled.” The cost and time of retraining or hiring additional resources can weigh significantly on an IT department. And as with your hardware decisions, look for a company that has a solid relationship with SAP and verifiable satisfied client references.
In 2007, SAP announced it would generally only support 64-bit operating environments for new installations going forward. As SAP software evolves and low-cost 64-bit hardware becomes more prevalent, the need to run 32-bit servers and therefore 32-bit operating systems is falling by the wayside. Don’t waste your time on such environments. Unless the company is already running an older version of SAP or has some odd bolt-on software only supported in 32-bit environments, there is simply no need to run a 32-bit server and OS in an SAP environment anymore.
Basic OS Features
Some of the features to look for in an OS are memory management, crash recovery, patch management, security, and advanced features such as clustering capabilities. Other things to consider when choosing an OS are support for third-party management utilities or the presence of built-in ones. Take a look at how the management and monitoring solutions in your IT environment today might fit with your prospective SAP solutions and the possible OS choices you face. Utilities such as monitoring applications, virus-scanning utilities, and backup software need to be validated to make sure they will work with existing toolsets as well as with SAP. In some cases, new toolsets must be invested in, which may not be cost effective or consistent with your IT department’s future vision.
SAP File Systems and the Role of the OS
SAP in relationship to an OS is a set of executables and libraries that allow users though various front ends to connect to application servers to submit and retrieve data to an SAP database. SAP starts multiple OS-level services and processes, thereby making efficient use of a server’s available memory and CPU power. A UNIX or Linux OS containing an SAP instance has a directory named /usr/sap (or x:\usr\sap in the case of Windows) that contains several subdirectories with executables, log files, and profiles. In Windows, x:\usr\sap is shared as SAPMNT and is accessible as \\servername\sapmnt. On a Windows server with multiple instances of SAP and a single OS installation, all SAP instances must be installed to the same SAPMNT directory; there can be only one SAPMNT share. In UNIX, /sapmnt is mounted as an NFS (network file system) mount, whereas /usr/sap/<SID> is a local file system.
In both UNIX and Windows, the SAP system identified (SID) is at the next directory level. See Figures 4.2 and 4.3 for the SAP directory structures of a Windows and a UNIX system for SAP, respectively. In Windows, the service SAPOSCOL runs the OS collector and allows SAP to gather OS-related performance and other statistics such as CPU utilization, memory utilization, disk input/output (I/O) activity, and more. All SAP systems contain one instance of the OS collector, although this collector is not required for SAP system operation.
)
Figure 4.2 SAP file systems installed on Windows SAP systems.
)
Figure 4.3 SAP file systems installed on UNIX-based SAP systems.
Another Windows service is SAPService<SID>, where <SID> is the system identifier of the SAP instance. One SAPService<SID> exists for each instance of SAP on a machine, and it is started using sapstartsrv.exe. The service is started by the SAP service account of the <SID>adm account, depending on SAP version. This service calls the SAP start profile, which tells the system how to start SAP and registers a number of environmental variables. Suffice it to say here that these matters can be fairly complex.
The term SAP system refers to a single system or collection of systems hosted by one database that uses one SID name (system identifier). For example, an SAP ERP production system named PRD may consist of one database (nearly always), one central instance, and perhaps two, eight, or sixty different application servers, depending on workload. This collection of multiple SAP instances and the database make up an SAP system. Thus, an SAP instance is synonymous with one installed component (or “installation”) of SAP on a server (also called a “host”). One host can contain multiple SAP instances, too, which belong to different SAP systems.
SAP OS-Level Work Processes
At an OS level, SAP has eight different work process types, as detailed in Table 4.2. Sometimes you will see them referenced as DVEBMSG. The D equates to dialog work processes, whereas the V references update work processes (differentiated by V1 and V2 priority types), E is enqueue, B is for background/batch jobs, M is the message service, S is used for print spooling, and G represents the SAP gateway. The instance profile of an SAP instance dictates how many of each type of process will start at system startup time. You can see which work processes your OS is running by running an applet or utility on the OS itself or using SAP’s own transactions SM50 and SM66. Though we are getting ahead of ourselves, this ability to review the status of your SAP work processes is very important; beyond providing a view into the system’s workload, it also reveals in real time the status of the system in terms of what each work process is performing on a particular SAP instance or group of instances. SM50 shows you only the work processes on the current application server you are logged in to, whereas SM66 gives you a global work process overview; SM66 is your window into what is happening with every active work process running across an entire SAP system.
Table 4.2. SAP Work Processes
|
Work Process Type |
Description |
|
Dialog |
D: Processes real-time information in the foreground. |
|
Background |
B: Background processing for long-running processes, reports, and batch jobs. |
|
Synchronous Update |
V1: Processes immediate updates to the database. |
|
Asynchronous Update |
V2: Processes updates to the database on a lower priority than V1 (that is, when time permits). |
|
Enqueue |
E: Manages database locks. |
|
Message |
M: Manages communication between application servers. |
|
Spool |
S: Manages print jobs (the print spool). |
|
Gateway |
G: Communicates with other SAP and non-SAP systems. |
SAP OS-Level Profiles
SAP contains three profiles: the default, start, and instance profiles. Profiles are essentially text files that, for the purposes of version control, are imported into and maintained by the SAP database. The default profile contains information common to all instances of SAP in an SAP system. For example, PRD may have a database, central instance, and three application servers; these would all use the same default profile. The start profile calls the executables to start SAP. Finally, the instance profile contains detailed information for each SAP instance in a system that makes up a common <SID>. This detailed information reflects specific memory configuration parameters, defines how buffers and work processes are defined and utilized, and a myriad of other information as well. Use SAP transaction RZ10 to change and maintain all these profiles, and to access a handy list of all available profile parameters.