Hi Vasanth,
As far as I know and understood The Concept is :
It depends on HANA Landscape, from your picture - I can assume that - its a shared disk storage which is connected with different nodes of HANA within the same HANA site.
- Storage based mirroring of SAP HANA disk areas controlled by storage technology
- WARM standby: DATA and LOG content is continuously transferred to secondary site under control of SAP HANA database
- HOT Standby: DATA content is only initially transferred to secondary site, afterwards continuous LOG transfer and LOG replay on secondary site
For more detail you can also refer HA on SPS06 : Introduction to High Availability for SAP HANA | SAP HANA
The SAP HANA database system supports high availability with a failover scenarios for hosts. It is possible to have standby hosts that can take over if an active host should fail – for example because of hardware failure. The standby hosts work in “cold” standby mode. This means that they just register with the Master Name Server and wait.
As long as they are in standby mode the Index Servers on these hosts do not contain any data and do not receive any requests. When an active host fails, this is detected by the Master Name Server which selects a standby host to take over. The Index Server on the selected standby host takes over the database volumes of the failed Index Server and loads the data into memory by executing the restart sequence.
Assigning the volumes of the failed host to the standby host requires having the database volumes on a shared storage server. Therefore this high availability scenario is called cold
standby with shared storage.
For large amount of data, loading the data into memory during failover may take considerable time. In “hot” standby mode, the standby server would be kept close to the state of the original server to allow a very fast takeover. This would require replicating all changes to the standby server during normal operation, for example by replicating the transaction logs and replaying them on the standby server. But what happens if the host with the Name Server fails? To ensure high availability of the Master Name Server, up to two Slave Name Servers can act as backup Master Name Servers. If the current Master Name Server fails, the backup Master Name Server
takes over. If two backup Master Name Servers are configured, they negotiate and one of them takes over the role of the Master Name Server. The new master then performs a restart from the persisted data and transaction logs of the old master. This is similar to the process described above for the Index Servers. You may wonder why the new Master Name Server needs to restart?? As a former slave server it received all data already via replication. The reason is transactional consistency: replication is not guaranteed to be immediately consistent. The most recent changes might be missing in the slave name server. Only by restarting from the persisted data it can be assured that all committed changes are restored.
Regards
Kumar