As an SAP HANA database administrator, you need to install and administer your company’s high availability scale-out SAP HANA systems. You need to have hands-on experience with installing SAP HANA single-host systems and extending such a system with additional hosts.
The SAP HANA database life cycle manager can be used to install an SAP HANA multiple-host system in one of the program interfaces and with a combination of parameter specification methods.
A multiple-host system is a system with more than one host that can be configured as active worker hosts or idle standby hosts. The SAP HANA software is built for a flexible architecture that allows a distributed installation. This means that the load can be balanced between different hosts. The SAP HANA software can be installed on a shared file system environment. This shared file system must be mounted by all hosts that are part of the system.
A multiple-host system can be installed as a new system on several hosts, or by adding one or more new hosts to an already installed single-host system. To add hosts to an existing system, use the SAP HANA resident HDBLCM.
It is important to review multiple-host system concepts, such as host grouping and storage options, before installing a multiple-host system.
When configuring a multiple-host system, the additional hosts must be defined as worker hosts or standby hosts (worker is the default). Worker machines process data; standby machines do not handle any processing and instead just wait to take over processes in the case of worker machine failure.
As an in-memory database, SAP HANA is not only concerned with maintaining the reliability of its data in the event of failures, but also with resuming operations with most of that data loaded back in memory as quickly as possible. Host auto-failover is a local fault recovery solution that can be used as a supplemental or alternative measure to system replication. One (or more) standby hosts are added to an SAP HANA system, and configured to work in standby mode.
Before installing a multiple-host system, it is important to consider whether high availability is necessary, and how hosts should be grouped to ensure preferred host auto-failover. For host auto-failover to be successful, if the active (worker) host fails, the standby host takes over its role by starting its database instance using the persisted data and log files of the failed host. The name server of one of the SAP HANA instances acts as the cluster manager that pings all hosts regularly. If a failing host is detected, the cluster manager ensures that the standby host takes over the role and the failing host is no longer allowed write access to the files (called "fencing") to avoid data corruption. The crash of a single service does not trigger failover because services are normally restarted by hdbdaemon .
Host grouping does not affect the load distribution among worker hosts. The load is distributed among all workers in an SAP HANA system. If there are multiple standby hosts in a system, host grouping should be considered, because host grouping decides the allocation of standby resources if a worker machine fails. If no host group is specified, all hosts belong to one host group called "default". The more standby hosts in one host group, the greater the failover security.
If each of the standby hosts is in a different host group, the standby host in the same group as the failing worker host is preferred. If a standby host is not available in the same host group, the system tries to fail over to a standby host that is part of another host group. The advantage of this configuration is that in an SAP HANA system with mixed machine resources, similar sized machines can be grouped together. If a small worker host fails, and a small standby in the same group takes over, the processes are moved to a machine with similar resources, which allows processing to continue as usual with optimal resource allocation.
If you use SAP Business Warehouse to apply a temperature-based data strategy, you can significantly optimize the usage of memory and hardware resources by reserving one node of the scaled-out SAP HANA landscape exclusively for warm data. In information life cycle management, multi-temperature strategies are often applied whereby data is classified by access frequency as either hot, warm, or cold. Depending on this classification and data usage, this data is stored in different memory areas.
A multi-temperature memory strategy may be required for different reasons, for example:
The standard SAP HANA sizing guidelines allow for a data footprint of 50% of the available RAM. This ensures that all data can always be kept in RAM, and there is sufficient space for intermediate result sets. These sizing guidelines can be significantly relaxed on the extension group, as warm data is accessed less frequently, with reduced performance SLAs, with less CPU-intensive processes, only partially at the same time.
To implement a multi-temperature memory strategy, you can assign hosts to worker groups. Hot and warm data are then distributed across hosts. To increase performance and memory usage, a worker node is assigned to a separate extension node. Unlike the standard nodes (coordinator and worker), the extension node is intended exclusively for data that is not accessed as frequently (warm) as other data (hot). For more information, see SAP Note: 2453736.
In single-host SAP HANA systems, it is possible to use local file systems residing on directly-attached internal or external storage devices, such as SCSI hard drives, SSDs, SAN storage, or NAS. However, to build a multiple-host system with failover capabilities, this is not sufficient. Either the chosen file system type or the SAN infrastructure, along with an SAP HANA functionality capable of disc fencing, must ensure the following:
There are two fundamentally different storage configurations that meet these two conditions: shared storage devices or separate storage devices with failover reassignment. Do not confuse shared storage with the installation directory /hana/shared that must be shared across all hosts.
A shared storage subsystem, which is accessed using file systems such as NFS or IBM's GPFS, makes it easy to ensure that the standby host has access to all active host files in the system. In a shared storage solution, the externally attached storage subsystem devices can provide dynamic mount points for hosts.
As shared storage subsystems vary in their handling of fencing, it is the responsibility of the hardware partner and their storage partners to develop a corruption-safe failover solution that is specific for the file system used to access that storage subsystem. An NFSv3 storage solution must be used in combination with the storage connector supplied by the hardware partner. NFSv4 and GPFS storage solutions can optionally be used with a storage connector. A shared storage system could be configured as in the following figure. However, mounts may differ among hardware partners and their configurations.
It is also possible to assign separate storage to every SAP HANA host, which has nothing mounted except the shared area. An SAN storage must be used in combination with the SAP Fiber Channel Storage Connector, which SAP HANA offers to storage technology vendors. During failover, SAP HANA uses the storage connector API to tell the storage device driver to re-mount the required data and log volumes to the standby host, and fence off the same volumes from the failed host.
In a non-shared environment, separate storage is used in combination with the storage connector API. For more information about the storage connector API, see the SAP Fiber Channel Storage Connector Admin Guide available in SAP Note: 1900823.
An SAP HANA system can be configured as a multiple-host system during installation, using the SAP HANA database life cycle manager (HDBLCM) from the installation media. It is also possible to add hosts after the installation of a single-host or multiple-host SAP HANA system, using the resident SAP HANA database life cycle manager.
Use the SAP HANA database life cycle manager graphical user interface, the command-line interface, or the SAP HANA database life cycle manager Web user interface, to add one or multiple hosts to an existing SAP HANA system. The configuration options change depending on how the host is added.
The first consideration is whether the host you are logged on to is integrated in the system. If you are logged on to a configured system host, then you are on an integrated host and adding a non-integrated host to the system.
If you are adding a host to a single-host system, the listen interface is automatically configured to global during the host addition. After the host is added to the system, the internal network address can be defined and the inter-service communication can be re-configured to a different setting, if required.
The following prerequisites must be fulfilled before hosts can be added to a SAP HANA system:
