Show TOC

Process documentationPotential SPOF Checklist Locate this document in the navigation structure

 

There are a number of potential single points of failure (SPOFs) in most systems and you need to be aware of these before you start to build high availability into your system. However, what constitutes a potential SPOF depends on your particular system configuration. For example, a disk drive might be a potential SPOF in a given system configuration but not when mirrored. The major potential SPOFs are listed below, grouped into the main system areas.

See also System Failure (SAP NetWeaver AS).

Prerequisites

SAP suggests that, for each component of a planned or installed SAP system listed in this process, you assess the following:

  • Is the component a SPOF in your particular system configuration?

  • Can you afford the risk of failure for a particular SPOF?

Note Note

Risk analysis using checklists

Before you start to build high availability into the systems at your site, SAP strongly advises you to try and quantify which of the items listed in this SPOF checklist and in the general checklist are relevant for you. After you have ranked the vulnerable aspects of your system according to the costs of failure – for example, whether you need to call in an external engineer, order a replacement part, and so on – you can then start improving availability.

End of the note.

Process

  1. You consider redundant configuration of the SAP services dialog, update, batch, gateway, and spool – that is, on multiple host machines – to improve availability. This means that these services are not potential single points of failure. You can improve the availability of the message service by the use of high-availability solutions. For more information, see SAP NetWeaver AS ABAP: High Availability and SAP NetWeaver AS Java: High Availability.

  2. You consider configuration of the database service to overcome its potential single points of failure:

  3. You consider the database-specific recommendations in the following table (databases are listed in alphabetical order):

    Database

    Single Points of Failure (SPOFs)

    IBM DB2 for i

    IBM DB2 for Linux, UNIX, and Windows

    For more information about high availability, see High Availability for IBM DB2 for Linux, UNIX, and Windows.

    IBM DB2 for z/OS

    You can also use a standby database to protect the data against disaster. See also Replicated Standby Database for DB2 for z/OS and Data Sharing for DB2 for z/OS.

    See also System Automation Software on DB2 for z/OS.

    MS SQL Server

    See the following high-availability solutions:

    Oracle

    • Database Instance

      • Database background processes (DBWR, LGWR, SMON, PMON...)

      • Memory structures (SGA, semaphores)

      You can protect the database instance using high-availability software or replicated database servers (only available for certain databases).

    • Database files

      • Control file

      • Current online redo log file

      • Data files

      You can protect the control file and the current online redo log file by using Oracle or proprietary disk mirroring. You can protect the data files by using disk mirroring. Make sure that you also protect all files by doing backups.

    You can use Oracle standby databases for a more comprehensive high-availability solution that can withstand a disaster at one site.

    SAP MaxDB

    • Database as a whole

      You can protect the database instance using high-availability software.

    • Data within the database

      You can protect all relevant data by using hardware-based disk mirroring for all data volumes and log volumes of your database. If you do not want to use hardware-based mirroring for your log volumes, we recommend software-based mirroring of the log volumes using the log mode function of SAP MaxDB. In any case, you also need to perform regular data and log backups.

      For more information, see Planning Databases.

    You can use the SAP MaxDB Standby Database or SAP MaxDB Hot Standby for a more comprehensive high-availability solution that can withstand a disaster at one site.

  4. You consider network-specific recommendations for:

  5. You consider hardware and system software. For more information, see System Failure (SAP NetWeaver AS).

  6. You consider disk technology.

    Potential single points of failure in the hardware of a disk system include the following:

    • Power supply

    • Fan and cooling

    • Internal/external cabling

    • SCSI path from host machine to device

    • Internal system bus

    • Write-cache:

      • Nonvolatile SIMMs or battery backup serve to address power failure

      • Mirrored SIMMs to address SIMM failure

    • Read-cache: nonvolatile SIMMs optional

    • Battery power for the device to store cache to disk in case of power failure

    • Controller

    • Microcode

    • Disk-internal storage processors

    • RAID internal storage maps

    • Disk spindles

    • Spindle mechanism

    Potential single points of failure in the disk-based data are the following:

    • SAP user data

    • SAP system data

    • Software components:

      • The SAP system

      • DBMS and log files

      • Operating system and swap space

    • Root file system

  7. You consider setting up the SAP flexible license mechanism with two license servers.

    For more information, see Flexible License Mechanism.