An Architect's vision

SAP HANA System Replication is a reliable high availability and disaster recovery solution that provides continuous synchronization of a HANA database to a secondary location either in the same data center or remote site. System Replication is a standard SAP HANA feature. In this method, all data is replicated to the secondary site and data is pre-loaded into memory on the secondary site which helps to reduce the recovery time objective (RTO) significantly. So in case of a failover, the secondary site will be able to take over without even performing a HANA DB (re)start and will work as primary DB straightaway. Once the system replication is configured properly, each HANA internal process (nameserver, indexserver etc) connects to its counterpart on the secondary site, and all logged changes in the primary location are replicated to secondary site continuously through persisted redo logs. While system replication is running, the secondary site is on standby mode with data already

 way to do replication on HANA DB-level replication can not pay the extra cost of replication solutions. 3.We will explain in more detail how the System Replication, which provides HANA. When they configure the HANA DB configured as 2 System Replication Node 1 times (suse01) is always an Active state to provide services. Node 1 = Primary time server = Active Server Node 2 = Standby time = Secondary Server

There are 4 log replication modes: Synchronous in-memory (syncmem) :  This is the default log replication mode. In this mode, primary node waits for the acknowledgement confirming the log has been received by the secondary node before committing any transactions.  Basically, primary node waits until secondary node has received data and as long as the replication status is ACTIVE for  all  services, there will not be any data loss.  The waiting period of the primary system is determined by parameter named  logshipping_timeout  in global.ini. Its default value is 30 secs and if there is no acknowledgement received from the secondary node after 30 secs, primary node continues without replicating the data. Synchronous (sync) :  In this mode, primary node waits for acknowledgement confirming the log has been received AND persisted by the secondary node before committing any transactions. The key benefit of this option compared to syncmem is the consistency between primary and se

VM is the most favored option, and is an effective platform to run Docker hosts; you can also run containers on bare metal as depicted in the below architecture.

As previously established, the containers are a stateless process, so you don’t need to back up and patch them. All the applications and data live in the shared Docker volume, which is shared between containers; hence, you only need to back up and patch the main system.

No. Container is the virtualization on the top of OS whereas VM is the virtualization of Compute resources.   A VM takes everything that used to sit on the physical server and stores it under the VM; this includes applications, operating systems, the library and data.  A VM packs it all in a single image to move around. However, containers use the underlying Docker resources to build the image or add and remove services as you need them.

A Docker container is the abstraction of the application or services that help to make an application. Dockers are very lightweight micro services that encapsulate only the application code and binaries and libraries.  The containers can also share their binaries/libraries, as they don’t have individual operating systems. As a result, scaling the application through containers is much easier than using virtual machines (VMs).