Multiple-Host System Concepts

It is important to review multiple-host system concepts like host grouping and storage options before installing a multiple-host system.
Host Types
When configuring a multiple-host system, the additional hosts must be defined as worker hosts or standby hosts (worker is 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.
Auto-Failover for High Availability
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 a 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) so that they do not become corrupted. The crash
of a single service does not trigger failover since services are normally restarted by hdbdaemon . For more information, see Setting Up Host Auto-Failover in the SAP HANA
Administration Guide.
Host Grouping
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 more failover security.

If the standby hosts are each in a different host group, the standby host in the same group as the failing worker host is preferred. Only if no standby host is available in the same
host group, the system will try to fail over to a standby host, which is part of another host group. The advantage of this configuration is that in an SAP HANAsystem 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.
Storage and File System Options
In single-host SAP HANA systems, it is possible to use local file systems residing on direct-attached internal or external storage devices, such as SCSI hard drives, SSDs, SAN
storage, or NAS. However, in order 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 a SAP HANA functionality capable of disc fencing must ensure the following:
The standby host has file access to data and log volumes of the failed host.
The failed worker host no longer has access to write to files - called fencing.
There are two fundamentally different storage configurations which meet the two conditions above: 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.
Shared File Systems
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 are capable of providing dynamic mount points for hosts. Since 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 which 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 diagram below, however mounts may differ among hardware partners and their configurations.
Non-shared Storage
It is also possible to assign every SAP HANA host a separate storage, which has nothing mounted except the shared area. A SAN storage must be used in combination with
the SAP Fiber Channel Storage Connector, whichSAP HANA offers 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 logs 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 in Related Information.