Business Example
As an SAP HANA database administrator, you are responsible for your company’s SAP ERP and SAP Business Warehouse (BW) systems. You need to understand the SAP HANA startup framework, and how the SAP HANA database handles hardware and software faults.
Service Auto-restart
In the event of a software failure that disables one of the configured SAP HANA services (index server, name server, and so on), the failing service is restarted by the SAP HANA Service Auto-Restart watchdog function, which automatically detects the failure and restarts the stopped service process. Upon restart, the service loads data into memory and resumes its function. While all data remains safe (RPO=0), the service recovery takes some time.
The restarting of the failing SAP HANA services is handled by the SAP HANA daemon service. One of the tasks of this service is to watch over the other hdb* services and restart them if necessary. The SAP HANA daemon itself is started by the SAP HANA startup framework. This framework resembles the SAP NetWeaver startup framework and is shown in the figure SAP HANA Startup Framework.
When a Linux server boots, the boot process goes through several stages that are executed by different components:
- The BIOS/UEFI
After turning on the computer, the BIOS or the UEFI initializes the different basic hardware components, such as the screen and keyboard, and tests the main memory. As soon as the first bootable hard disk is identified, the BIOS/UEFI passes control to the boot loader.
- The Boot Loader
- Located on the first data sector of the first hard disk, the master boot record is loaded into the main memory. On Linux systems, this boot loader is usually GRUB 2. When the boot loader is finished, it passes control to the operating system.
- The Operating System
- When the boot loader passes control to the operating system, the Linux kernel and initial RAM-based file system (initramfs) are loaded into memory.
- The init process
- From the initramfs, the init executable is started, and then it mounts the root file system. When the root file system is successfully mounted, control is passed to the systemd daemon. The initramfs file system is cleared.
- The systemd daemon
The systemd daemon takes care of the booting of the rest of the operating system. The systemd daemon mounts all the defined file systems and starts the required services. When this is finished, the Linux operating system is available for the user.
When a Linux server boots, as described in the previous steps, the systemd daemon identifies into which "target" (formerly known in System V as "runlevel") the server needs to be started. When the target runlevel is identified, the systemd daemon starts the required programs belonging to that target runlevel.
An overview of the available target runlevels on the server can be generated with the command systemctl list-units --type=target.
In the different target runlevels, only the required start scripts, programs, or daemons are started. One of these start scripts is the sapinit script found in the /etc/init.d folder. The sapinit script is installed on the server during the SAP HANA installation. The following steps are executed during start-up:
The sapinit script reads the /usr/sap/sapservices file and starts the sapstartsrv daemon.
The sapstartsrv then reads the SAP HANA instance profile and starts the sapstart executable.
The sapstart program reads the SAP HANA instance profile also to see if the SAP HANA database needs to be started automatically.
From the SAP HANA cockpit 2.0 in the Manage Services application, all the running SAP HANA services are shown. The column Process ID is very interesting here, as it shows the process ID (PID) of the SAP HANA services. The PID of the daemon process is also shown. This PID can also be found at the Linux operating system level. In this way, you can easily identify the SAP HANA services at the operating system level.
The process list can also be shown at the Linux operating system level. Showing processes under Linux can be done in many ways, for example, using the command ps fx -o ppid,pid,args --sort=ppid.
This command not only shows the PIDs of all the SAP HANA services, but also their starting order and hierarchy. In the previous figure, Operating System Process Overview, it is clearly visible that the init process starts the sapstart.
The sapstart process in turn starts the SAP HANA daemon process. In the operating system process overview, this process is not called daemon, but by looking at the PID, you can see that it is indeed the SAP HANA daemon.
The SAP HANA daemon, often referred to in the documentation as hdbdaemon, is responsible for starting all the other SAP HANA services such as:
hdbnameserver
hdbcompileserver
hdbpreprocessor
hdbindexserver
hdbxsengine
hdbwebdispatcher
This previous list is not fixed, as it depends on the SAP HANA version and on the SAP HANA tenant configuration.
SAP HANA Autostart
The SAP HANA database can be started, stopped, and restarted at the Linux operating system level. This is often needed to automate tasks. The scripts need the information contained in the startup profile.
The startup profile can be found in the location /usr/sap/<SID>/SYS/profile. The startup profile lists the SAPSYSTEMNAME, SAPSYSTEM, INSTANCE_NAME, and SAPLOCALHOST, but none of these parameters should be modified.
The only exception is the Autostart parameter. This parameter controls the automatic start of the SAP HANA database by the sapstart process. It can have the following values:
If Autostart=0, the SAP HANA database does not automatically start when the operating system starts.
This can be very useful if there are several SAP HANA databases (such as, end-user training and test) installed on one server that should be manually stopped and started as needed by the system administrator.
If Autostart=1, the SAP HANA database starts automatically when the operating system starts.
This can be very useful for a production system that needs to be available as soon as possible after a hardware failure, or for an SAP HANA database that should be automatically available after the scripted deployment of a fresh virtual image.
Host Auto-failover
Host auto-failover is a local "N+m" (m is often 1) fault recovery solution that can be used as a supplemental or alternative measure to the system replication solution described earlier. One (or more) standby hosts are added to an SAP HANA system and configured to work in standby mode. As long as they are in standby mode, the databases on these hosts do not contain any data and do not accept requests or queries.
When an active (worker) host fails, a standby host automatically takes its place. Because the standby host may take over operation from any of the primary hosts, it needs access to all the database volumes. This can be accomplished by using a shared, networked storage server, by using a distributed file system, or with vendor-specific solutions that use an SAP HANA programmatic interface (the Storage Connector API) to dynamically detach and attach (mount) networked storage (for example, using block storage over Fiber Channel) upon failover.