SAP HANA SYSTEM REPLICATION SETUP with Hands-on Lab Access

所在平台: Udemy

课程主页: https://www.udemy.com/course/sap-hana-system-replication-setup-with-hands-on-lab-access/

课程评论:没有评论

第一个写评论        关注课程

课程简介

本课程“SAP HANA 系统复制设置与实操实验访问”旨在深入介绍SAP HANA系统复制机制。 **课程概要:** SAP HANA 系统复制是确保SAP HANA系统高可用性的关键技术。SAP推荐使用该配置来降低计划内维护、故障和灾难导致的SAP HANA系统停机时间,支持0秒恢复点目标(RPO)和分钟级恢复时间目标(RTO)。 **核心内容:** 1. **系统复制的定义与目的:** 解释系统复制是SAP为实现高可用性和减少停机时间而设计的,其主要目标是提供即时的数据同步和快速的故障转移能力。 2. **系统复制的架构与工作原理:** * **复制结构:** 描述了次级系统作为主级系统的精确副本,需要相同数量的主机(待机主机数量可不同),并强调了主次级系统间可靠连接的重要性。 * **通信机制:** 说明了主次级系统中的每个服务进程都会与其对应的进程进行双向通信,次级系统通常不接受请求或查询(除非启用Active/Active读模式)。 * **部署场景:** 阐述了次级系统可部署在主级系统附近以应对本地故障和计划停机,也可部署在远程数据中心以实现灾难恢复。 * **实时复制模式:** 详细介绍了次级系统在实时复制模式下的工作状态,包括不断与主级系统通信、复制并持久化数据和日志,以及通常将数据加载到内存中。 3. **数据同步过程:** * **首次同步:** 当系统复制启用后,次级系统会向主级系统请求数据快照。 * **持续同步:** 此后,主级系统发生的所有日志更改都会被持续复制到次级系统。 * **日志传输:** 主级系统中的持久化日志(写入日志卷)会立即发送到次级系统。 4. **安全性考量:** * 强调了保护主次级系统间内部通信渠道安全的重要性,例如通过防火墙控制端口、网络隔离、VPN或IPSec等。 * 建议使用专门的高速网络进行连接,这些网络通常已具备安全措施。 5. **复制模式与操作模式:** * **事务提交:** 提及了事务提交与重做日志复制之间的关系,这取决于所选的复制模式。 * **连接中断处理:** 解释了当主次级系统连接中断或次级系统崩溃时,主级系统(在短暂超时后)会恢复操作,并提到日志在次级系统中的处理方式取决于操作模式。 6. **故障转移(Takeover):** * **待机状态:** 在系统复制运行时,次级系统处于待机状态,直到执行故障转移。 * **故障转移过程:** 阐述了在发生需要完全系统接管的故障时,如何将次级系统从实时复制模式切换为完全操作模式。次级系统会通过回放最后的事务日志来恢复并开始接受查询,从而成为新的主级系统。 * **恢复与回滚:** 提及了当原主级系统恢复后,可以将其配置为新的次级系统或还原到原始配置。 7. **其他配置选项:** * **多层系统复制(Multitier System Replication):** 介绍了将一个二级系统复制为第三级系统的链式设置。 * **多目标系统复制(Multitarget System Replication):** 描述了主级系统可以同时向多个次级系统复制数据更改。 8. **许可 Validity:** * **自动复制:** 主级系统会自动将许可信息复制到次级系统,无需额外安装。 * **Active/Active (读模式) 许可:** 在Active/Active(读模式)配置下,次级系统也可能需要许可。 9. **系统要求:** * **系统一致性:** 强调复制系统通常需要相同,并引用了“配置SAP HANA系统复制的通用先决条件”主题以获取详细信息。 本课程通过理论介绍和实操实验访问,帮助学习者掌握SAP HANA系统复制的配置和管理,以实现关键业务系统的稳定运行和快速恢复。

课程评论(0条)

课程详情

Introduction to System ReplicationSAP HANA system replication is a mechanism for ensuring the high availability of your SAP HANA system.What is system replication?System replication is SAP's recommended configuration for addressing SAP HANA outage reduction due to planned maintenance, faults, and disasters. It supports a recovery point objective (RPO) of 0 seconds and a recovery time objective (RTO) measured in minutes.System replication is set up so that a secondary system is configured as an exact copy of the active primary system, with the same number of active hosts in each system. The number of standby hosts need not be identical. Furthermore, it requires a reliable link between the primary and secondary systems.Each service of the primary system communicates pairwise with a counterpart in the secondary system. The main difference to the primary system is that the secondary system does not accept requests or queries. The secondary system can accept queries only in an Active/Active (read enabled) configuration. For more information, see SAP HANA System Replication with Active/Active (Read Enabled).The secondary system can be located near the primary system to serve as a rapid failover solution for planned downtime, or to handle storage corruption or other local faults. Alternatively or additionally, a secondary system can be installed in a remote data center for disaster recovery. The instances in the secondary system operate in live replication mode. In this mode all secondary system services constantly communicate with their primary counterparts, replicate and persist data and logs, and typically load data to memory. The log and data can be compressed before shipping. For more information, see Data and Log Compression.How does system replication work?Once SAP HANA system replication is enabled, each server process on the secondary system establishes a connection with its primary system counterpart and requests a snapshot of the data. From then on, all logged changes in the primary system are replicated continuously. Whenever logs are persisted (meaning they are written to the log volumes of each service) in the primary system, they are also sent to the secondary system.The following graphic illustrates the general system replication processes:NoteTo prevent unauthorized access to the SAP HANA database, the internal communication channels between the primary site and the secondary site in a system replication scenario need to be protected. This may include filtering access to the relevant ports and channels by firewalls, implementing network separation, or applying additional protection at the network level (for example, VPN, IPSec). We recommend routing the connection between the two sites over a special site-to-site high-speed network, which typically already implements security measures such as separation from other network access and encryption or authentication between sites. The details of security measures and implementation of additional network security measures depend on your specific environment. For more information about network and security aspects, see the SAP HANA Master Guide and the SAP HANA Security Guide.A transaction in the primary system is not committed before the redo logs are replicated. This is determined by the selected replication mode when setting up system replication. For a detailed description of each replication mode, see Replication Modes for SAP HANA System Replication.If the connection to the secondary system is lost or if the secondary system crashes, the primary system (after a brief, configurable timeout) resumes operations. The way the received logs on the secondary system are handled depends on the selected operation mode. For a detailed description of each operation mode, see Operation Modes for SAP HANA System Replication.While system replication is running, the secondary system configured identically to the primary system is on standby until a takeover takes place.In the event of a failure that justifies a full system takeover, you switch the secondary system from the live replication mode to a full operation mode. The secondary system, which already preloaded the same column data as the primary system and possibly is already read enabled, becomes the primary system by replaying the last transaction logs and then starts to accept queries. When the original system can be restored to service, it can be configured as the new secondary system or reverted to the original configuration.Which other setups are possible?Besides the above presented standard setup, in which a primary system ships all the data to the secondary system, you can also configure a multitier or a multitarget system replication.In a multititer system replication, a tier 2 system replication setup can be used as the source for replication in a chained setup of primary system, tier 2 secondary system, and tier 3 secondary system. The primary system is always on tier 1. The replication source for the tier 2 secondary system is the primary system, while the replication source for the tier 3 secondary system is the tier 2 secondary. For more information, see SAP HANA Multitier System Replication.In a multitarget system replication, the primary system can replicate data changes to more than one secondary system. For more information, see SAP HANA Multitarget System Replication.What about license validity?The primary system automatically replicates relevant license information to the secondary system. No additional license needs to be installed, since the primary and secondary system have the same SID. For more information about licensing in SAP HANA system replication, see SAP Note 2211663.When using an Active/Active (read enabled) system replication configuration, the secondary system is subject to licensing. For more information, see SAP HANA Feature Scope Description.What other system requirements apply?In general, the replicating systems must be identical, but full details of prerequisites which apply and things you need to know before you start are given in the topic General Prerequisites for Configuring SAP HANA System Replication.

课程标签

0人关注该课程

主题相关的课程