SAP HANA 高可用性设置

什么是高可用性？
可用性通常表示为系统运行正常运行时间的百分比，在一年的过程中进行测量。例如，如果系统设计为 99.99% 的时间可用（有时称为“四个九”），则其每年的停机时间必须小于 0.01%，即 52 分 56 秒。这意味着每年的停机时间少于一小时。这可能是一个非常具有挑战性的目标。为了满足这些具有挑战性的目标，高可用性和容灾应该是架构设计的一个组成部分，即在基础设施的每一层上实现。

停机是停机的后果，可能是计划停机（如系统升级或硬件更换）或计划外停机（如软件或硬件故障）。意外停机可能由设备故障、软件或网络故障，或火灾、地震、区域断电或可能导致整个数据中心退役的施工事故等重大灾难触发。

高可用性是一组用于业务连续性的技术、工程实践和设计原则。这是通过消除单点故障（容错）和提供在系统中断后以最小的业务损失（故障恢复）快速恢复操作的能力来实现的。故障恢复是在由于故障而中断后恢复和恢复正常操作的过程。

灾难恢复是在由于数据中心或站点长时间故障而导致中断后恢复操作的过程。为灾难做准备可能需要跨更远的距离备份数据，因此可能更加复杂和昂贵。恢复 – 关键绩效指标 (KPI) 客户通常使用两个关键指标来指定系统中断后的恢复参数：恢复期目标 (RPO) 和恢复时间目标 (RTO)。系统的 RPO 和 RTO 如下图所示。

配置横向扩展 SAP HANA 系统

SAP HANA 数据库通过提供主机自动故障转移来支持分布式系统中的高可用性。如果活动主机发生故障，例如，由于硬件故障，备用主机可以接管，从而确保数据库的持续可用性。在 SAP HANA cockpit 2.0 中，您可以在 Host Failover 应用程序中监控各个主机的状态。要启动主机故障转移应用程序，请打开 SAP HANA cockpit 2.0 并导航到监控聚合运行状况应用程序。在 Aggregate Health Monitor 中，选择 SYSTEMDB@ 链接以打开 SAP HANA Cockpit 概览屏幕。在 SAP HANA Cockpit 概览屏幕上，搜索配置主机故障转移应用程序，然后选择配置主机故障转移链接。租户数据库 @ 也提供相同的应用程序，但此任务通常是您从 SYSTEMDB 执行的任务

故障转移的主机角色通常在安装期间配置。
使用 SAP HANA 主控室，您可以监控各个主机的状态并切换已配置的主机角色。您不能增加或减少相互关联的工作主机和备用主机的数量。更改已配置角色的主要原因是为移除主机做准备。在这种情况下，在停止主机上的数据库实例并移除主机之前，将名称服务器主机的配置角色更改为 SLAVE，并将索引服务器主机的配置角色更改为 STANDBY。通过在 nameserver.ini 文件的 Landscape 部分中设置 master 参数来完成重新配置。使用以下 SQL 命令，您可以指定哪三个主机是候选主机： ALTER SYSTEM ALTER CONFIGURATION ( ‘nameserver.ini’ , ‘SYSTEM’ ) SET (‘landscape’, ‘master’) = ‘wdflbmt7194:30001 wdflbmt7195:30001 wdflbmt7308： 30001’ 重新配置；使用以下 SQL 命令，您可以指定哪个主机是主机： ALTER SYSTEM ALTER CONFIGURATION ( ‘nameserver.ini’ , ‘SYSTEM’ ) SET (‘landscape’, ‘active_master’) = ‘wdflbmt7195:30001’ WITH RECONFIGURE;在 SAP HANA Cockpit – 主机故障转移中，您可以通过选择右上角的齿轮按钮来添加或删除显示中的列。在多主机 SAP HANA 系统中添加或删除主机时，删除状态列指示用于将数据移出您计划删除的主机的索引服务器的表重新分配操作的状态。在从单容器系统中删除活动主机之前，您必须将该主机的索引服务器上的表移动到系统中其余主机上的索引服务器上。一旦删除状态列中的值更改为 REORG FINISHED 或 REORG NOT REQUIRED，您就可以使用 SAP HANA 生命周期管理工具 hdblcm(gui) 物理删除主机。如果您的系统配置为多容器系统，Internal Use – Confidential 您必须先删除特定于租户的服务，然后使用 SAP HANA 数据库生命周期管理器删除主机。

可能的状态如下：
● <Empty>：主机未被标记为删除。
● REORG PENDING：需要重新分配操作才能将表移动到其他主机。
● REORG ACTIVE：重新分配操作正在进行中。有关详细信息，您可以查询系统表 SYS.REORG_OVERVIEW 和 SYS.REORG_STEPS。
● REORG FAILED：重新分发操作已执行但失败。有关详细信息，请查询系统表 SYS.REORG_STEPS。
● REORG FINISHED：重新分配操作已完成。可以卸载主机。
● REORG NOT REQUIRED：不需要重新分配操作。可以卸载主机。

在多主机系统的 SAP HANA 安装期间，会设置最佳自动故障转移配置。
以下设置中描述了最佳配置：
● Master 1：分配给执行安装的节点。
● Master 2：分配给分配给多主机系统的第一个附加节点
● Master 3：分配给分配给多主机系统的第一个备用节点。

如果没有配置备用主机，则使用分配给多主机系统的第二个附加节点。没有至少一个备用节点的设置将不是有用的高可用性方案。在我们的培训班环境中，我们在练习“安装高可用性 SAP HANA 系统”中执行的 SAP HANA 安装设置了最佳自动故障转移配置，如上图所示。出于教育目的，下一个练习“重新配置横向扩展 SAP HANA 系统”将向您展示如何使用 SAP HANA 主控室 2 中的主机故障转移应用程序重新配置自动故障转移配置。

这种改变的配置行为清楚地向我们展示了当从节点或主节点 1 发生故障时会发生什么。在上一个练习中，我们返回到最佳自动故障转移配置，并演示当主节点 1 节点发生故障，但主节点 3 节点分配给备用服务器时会发生什么。主机自动故障转移所需的授权

了解 SAP HANA 从属节点内部使用的故障
SAP HANA 节点主机的机密故障自动故障转移是一种本地故障恢复解决方案，可用于系统复制的补充或替代措施。将一个（或多个）备用主机添加到 SAP HANA 系统并配置为在备用模式下工作。如果它们处于待机模式，则这些主机上的数据库不包含任何数据，也不接受请求或查询。这意味着它们不能用于其他目的，例如质量或测试系统。当主（工作）主机发生故障时，备用主机会自动取代它的位置。如果名称服务器进程 hdbnameserver 和 hdbdaemon 都没有响应网络请求（因为实例已停止或操作系统已关闭或关闭），则将主机标记为不活动并触发自动故障转移。由于备用主机可以接管任何主要主机的操作，因此它需要对所有数据库卷进行共享访问。这可以通过共享网络存储服务器、使用分布式文件系统或使用 SAP HANA 编程接口、存储连接器 API 的供应商特定解决方案来实现，以便在故障转移时动态分离和附加（挂载）网络存储.

顾名思义，SAP HANA 的主机自动故障转移能力的特点如下：
● 故障转移在主机级别执行。一台主机的所有服务都移动到另一台主机上。单个进程（服务）的故障不会触发故障转移。
● 故障转移作为SAP HANA 的一个组成部分自动发生。不需要外部集群管理器。
● 数据一致性是关键要求。
如果允许故障主机（如上图中的原始主机 2）重新启动并将数据写入到与故障转移主机（上图中的新从属主机 3）并行的磁盘，则数据可能会损坏。为了始终确保数据的一致性，必须保证故障转移不会发生（或至少不会成功并且可能不会导致数据损坏）如果故障主机可以内部使用 – 机密可能仍然写入数据。为了实现这一点，SAP HANA 主机自动故障转移结合使用心跳和防护。

心跳
以下类型的心跳用于在将当前主机作为主机启动或执行故障转移之前检查另一台主机是否作为主机处于活动状态。
● 基于 TCP 通信的心跳：
– 使用 SAP HANA 内部通信协议从名称服务器 Ping 到名称服务器
– 使用 SAP HANA 内部通信协议从名称服务器 Ping 到 hdbdaemon
● 基于存储的心跳：当前主名称服务器定期更新位于不同存储分区上的心跳文件:
– SAP HANA 二进制文件的共享存储
– 主节点数据的存储分区
1 这些类型的存储通常与用于服务到服务通信的节点间网络以外的网络连接（例如用于 SAN 的光纤通道或用于 NFS 的专用以太网)，因此这些心跳提供了额外的价值。

防护
在极少数情况下，心跳无法检测到另一台主机是否还活着，例如在主机之间无法通信的脑裂情况下。 I/O 防护确保对方不再访问数据或日志存储。
SAP HANA 存储连接器 API 与特定的存储连接器一起，允许使用不同类型的存储和网络架构来确保正确的 I/O 防护：
● SAN 存储：使用 SCSI-3 的 SAP HANA 光纤通道存储连接器 [2]持久保留 (SCSI-3 PGR)。
● NFSv3：不使用文件锁定，但使用经过认证的存储供应商提供的存储连接器。这种类型的存储连接器实现了一个 Shoot The Other Node In The Head (STONITH) 调用以重新启动故障主机。如果 NFSv3 客户端（即 SAP HANA 服务器）死机，文件锁不会在 NFS 服务器端释放，从而导致任何想要访问这些文件的主机出现死锁。使用 nolock 挂载选项可以解决锁定问题，但使用此选项，数据无法防止来自不同主机的并行读取和写入。为了解决这个问题，必须实施 STONITH。
● NFSv4 或像 GPFS 这样的集群文件系统：使用文件锁。这里不需要存储连接器，因为这些文件锁可以可靠地防止错误访问。但是，一些存储供应商提供了 STONITH 类型的存储连接器来加速故障转移。

SAP HANA 多主机配置也可以从操作系统级别查看。
在 $DIR_INSTANCE/exe/python_support 文件夹中有一个名为 LandscapeHostConfiguration.py 的 Python 脚本。如上图所示运行脚本提供了配置的概述。除了 SAP HANA cockpit 2.0 视图之外，此脚本还显示以下主机列：
● STORAGE_CONFIG_PARTITION / 存储分区（已配置 – SPS 12 中的新增功能）：用于在故障转移后重新分配相同存储分区的稳定子路径。
● WORKER_CONFIG_GROUPS / Worker Groups（已配置——HANA 2 SPS 00 中的新增功能）：用于将主机分配给逻辑工作组的稳定分类值。
● WORKER_ACTUAL_GROUPS / Worker Groups（实际 – HANA 2 SPS 00 中的新增功能）：将主机分配给逻辑工作组的当前分类值。

主机故障检测。

主机故障检测规则
检查从主机（心跳）
1.主名称服务器ping所有其他名称服务器
（每10秒ping一次。5次ping丢失主机被视为不活动）
2.如果从属主机被认为是非活动的，则主名称服务器也会pingshdbdaemon。如果ping失败，将触发故障转移。
正在检查主主机
1.主1 ping主2和主3，主2 ping主3名称服务器。
如果一个硕士候选人在30秒内没有收到ping，它将ping主名称服务器。
2.当主名称服务器ping失败时，主hdbdaemon被ping。
如果主hdbdaemon在60秒内未应答，则主1被视为不活动。
3.名称服务器候选者检查存储器上的心跳文件。这些文件由Master 1每10秒更新一次。如果这些文件在60秒内未更新，则会触发故障转移。

主机故障是影响分布式 SAP HANA 系统的主机之间通信的主机的任何功能失调状态。为了检查主机的功能状态，名称服务器会定期在内部网络通信层向其他主机上的名称服务器发送 ping。在远程名称服务器不重复回复的情况下，将执行对 hdbdaemon 进程的附加 ping。只有当两个服务都没有及时回复时，才认为主机发生了故障。单个服务的崩溃不会触发故障转移，因为服务通常由 hdbdaemon 重新启动。如果服务因任何原因无法重新启动，则假定它也无法在另一台主机上启动。如果存储连接器返回错误，则名称服务器在启动期间自行中止是一个例外。然后它指示 hdbdaemon 关闭主机上的整个数据库实例，包括 hdbdaemon 本身，这允许其他主机进行故障检测和故障转移处理。

检查从主机
● 名称服务器通信心跳：当前主名称服务器每 10 秒 ping 一次所有其他名称服务器。如果名称服务器处于活动状态并且 5 次 ping 失败（立即或 60 秒 ping 超时后），则该名称服务器被视为非活动状态。通过多次 ping，SAP HANA 可以从短暂的网络中断中恢复，而不会触发故障转移。
● hdbdaemon 通信心跳：如果从属名称服务器被认为不活动（或已将其自身设置为不活动），则主名称服务器 ping 内部使用 – 机密从 hdbdaemon 进程。如果 hdbdaemon ping 失败（立即或在 60 秒 ping 超时后），则认为主机处于非活动状态并启动故障转移。检查Master主机
● 名称服务器通信心跳：名称服务器候选者，当前不是master，每隔10秒ping其他优先级较低的候选者。连同前面描述的从名称服务器心跳（当前主名称服务器 ping 所有其他名称服务器），通常 MASTER1 ping MASTER2 和 MASTER3，而 MASTER2 ping MASTER3。如果主候选在 30 秒内没有收到任何 ping，它会 ping 主名称服务器本身。
● hdbdaemon 通信心跳：如果ping master 名称服务器失败，则ping master 主机上的hdbdaemon 进程。如果 hdbdaemon 在 60 秒内没有响应，则当前主控主机被认为是非活动的。
● 名称服务器存储心跳：名称服务器候选主机检查心跳文件的变化，周期为 60 秒。当前主名称服务器每 10 秒使用主机名和随机字符串更新这些文件。仅当所有文件在 60 秒内未显示任何更改迹象时，才会开始故障转移。从主机故障转移到备用主机 当检测到故障并确定替换主机时，实际的故障转移过程开始。

故障转移步骤：
1 .目标主机选择
● 如果存在与对应的实际主机角色完全匹配的备用主机，则使用它。
● 如果存在与故障主机对应的角色之一的备用主机，则使用它。
● 如果故障主机具有SAP HANA 工作角色，则使用任何未分配的备用。
2. 主名称服务器调用所有已安装的 HA/DR 提供程序挂钩的 stonith() 方法和存储连接器 stonith() 方法。内部使用 – 机密 通常 stonith() 方法仅在 NFSv3 相关的存储连接器中实现，并重新启动故障主机 在拓扑中的两个主机之间交换所有服务的实际服务、主机角色、存储分区号和卷 ID，并通知所有其他主机。
4. 主名称服务器（选择了替换主机）调用目标主机上的名称服务器来执行故障转移。
5. 提升为新角色的主机调用 Storage Connectors attach() 方法来获取正确的存储分区（如果适用），并调用所有已安装 HA/DR 提供程序挂钩的 failover() 方法。

了解 SAP HANA 主节点故障转移算法的故障解释 与其他高可用性解决方案相比，SAP HANA 不使用由多个 SAP HANA 主机组成的仲裁来决定在初始启动或主故障转移时哪个主机可以成为主节点。通过心跳和防护，单个主机可以可靠地决定初始启动或主故障转移。使用备用主机但所有主候选都在使用中的主主机故障转移（双故障转移）

1.如果没有具有备用作为实际索引服务器角色的主名称服务器候选可用，则选择当前用作索引服务器从属的主候选之一作为新的主。
2. 主控主机的故障转移步骤如图中描述的场景，没有可用备用主机的主控主机故障转移。
3.之前分配的slave被标记为失败，进入failover队列。由于备用主机可用，从属故障转移在主故障转移后不久开始。
4. 两个故障转移并行执行

故障转移步骤：
1. 具有最高优先级（= 配置的名称服务器角色中的最小编号）的名称服务器主候选检测到故障情况并启动故障转移。
2. 如果名称服务器候选可用且当前是备用主机，则故障转移将转发到该主机。这避免了双重故障转移（参见下面的第二个示例）。
3. 故障转移包括与前面描述的从主机故障转移场景相同的步骤。
4. 名称服务器从磁盘重新加载其持久性。

目标主机选择
本节介绍替换主机的选择过程。
从 SPS11 开始，考虑实际主机角色 (HOST_ACTUAL_ROLES)。对于 SAP HANA 1.0 SPS11 及更高版本：
● 如果存在与相应实际主机角色完全匹配的备用主机，则使用它 如果故障主机具有 SAP HANA 工作角色，则使用任何未分配的备用主机。

对于 SAP HANA 1.0 SPS10 及更早版本：
● 如果有备用主机，则使用它。
● 如果有多个等效选项可用，则使用第一个主机。

搜索步骤仅限于同一个故障转移组，除非配置了 global.ini/[failover]/cross_failover_groups=false。内部使用 – 机密 如果没有可用的主机，则不会发生故障转移并且 HOST_STATUS 显示 ERROR。没有可用备用主机的主控主机故障转移 没有备用主机的分布式环境也可以执行故障转移以确保主控主机始终可用。当然，从属主机（以及位于那里的所有表）在故障转移后无法访问。通过删除 SAP HANA 主控室中的名称服务器角色 MASTER 2 和 MASTER 3，可以禁用此故障转移机制。如果您在每个主机上使用（不推荐）本地存储，或者格局由外部集群管理器控制，则需要禁用。名称服务器从属（非主候选）在系统重新启动时的等待超时与主候选不同。中止启动之前到达主名称服务器的重试次数由以下参数控制：nameserver.ini/[failover]/slave_to_master_startup_retries=10。因为一次重试不成功后的等待间隔是5秒，所以默认参数值10导致最大等待时间为50秒

具有最高优先级的名称服务器候选主节点检测故障条件并自行执行故障转移步骤。
2. 新的主名称服务器调用所有已安装 HA/DR 提供程序挂钩的 stonith() 方法和存储连接器 stonith() 方法（如果适用）以重新启动故障主机。一种。如果 STONITH 失败，故障转移将中止，新的主节点将自行关闭。湾。 （可能）剩余的第三个候选主节点然后重试故障转移。 如果这也失败了，则整个环境中都没有可用的主服务器，并且从属主机最终会自行关闭。
3. 新的 master 停止所有的服务（除了 hdbdaemon 和 nameserver）。
4. 新的master对旧的存储分区调用Storage Connector的detach()方法，对存储分区1（mnt00001目录）调用attach()方法，并调用所有已安装的failover hook的failover()方法：
a.如果失败，故障转移将中止，新的主节点将自行关闭。
b.（可能）剩余的第三个候选主节点然后重试故障转移。
c。如果这也失败了，那么整个环境中都没有可用的主控，并且从属主机会自行关闭。
5. 新的主名称服务器从磁盘加载其持久性。
6. 交换内部使用 – 机密当前存在的服务、主机角色、存储分区号、拓扑中两个主机之间所有服务的卷 ID，并通知所有名称服务器。
7. hdbdaemon 进程被重新配置，启动所有需要的服务。
8、被置换的slave主机角色保持不活动状态；该系统仅部分可用。
主机自动故障转移与外部集群管理器不使用内置的 SAP HANA 主机自动故障转移，您可以使用外部集群管理器监控和（重新）启动不同硬件上的虚拟主机。对于多个 SAP HANA 实例，这样做的好处是需要更少的备用主机，但另一方面，所有故障检测和防护逻辑都必须在外部实现。为避免不必要的 SAP HANA 控制的主故障转移，可以如前所述删除名称服务器 MASTER 2 和 MASTER 3 角色。服务故障自动关闭主机 对于每个服务，可以定义固定次数的重新启动，之后守护程序将自行停止。

在 daemon.ini 中为每种服务类型设置了相关参数： # 如果设置为 true，则守护进程将关闭主机上的所有服务 if # 此服务无法启动 startup_error_shutdown_instance=true # 如果服务在启动过程中失败，则重试次数 startup_error_restart_retries =4 名称服务器是唯一将后一个参数默认设置为 true 的服务。这意味着任何涉及常量名称服务器崩溃的问题最终都会停止守护进程。

例如，如果该服务的重复启动问题应该停止受影响的数据库实例，则提供的设置可用于索引服务器。 SAP HANA 和Split Brain 在SAP HANA 的主/从/备用故障转移方案中，整个系统中只有一个实体可以做出故障转移决策，即主名称服务器。从属主机或备用主机永远不会自行执行故障转移。因此，对于裂脑情况，只需要考虑主控主机。如果多个主机尝试成为主名称服务器/索引服务器并从磁盘访问同一组数据（持久性），SAP HANA 将遇到脑裂情况。这将不可挽回地破坏数据。为了克服这个问题，SAP HANA 使用 I/O 防护来阻止其他主机访问存储，如下所示：
● SAN 存储：存储设备被当前活动主机锁定，具有 SCSI-3 持久保留。如果另一台主机尝试挂载这些设备，旧主机会自动失去写入权限，并且服务会自行中止。
● NFSv3 共享存储：不能使用NFSv3 文件锁实现，因为如果NFSv3 客户端死机，锁不会被释放，因此存储供应商必须提供STONITH 过程，该过程会重新启动故障主机。
● NFSv4 共享存储或集群文件系统（如 GPFS）：文件锁定实现跨主机可靠工作。

主机不可用以及锁释放由文件系统处理。尝试打开已打开的持久性的主机失败并自行中止。基于通信网络和存储网络的心跳用于检测其他主机的活动性并防止不必要的故障转移尝试。如果目标主控主机检测到另一个主控仍然处于活动状态，它会自行终止以让另一个主控继续运行。如果没有这个，不同的主机可能会尝试成为主人并会反复相互隔离。在脑裂的情况下，有时会使用法定人数来决定哪一方应该“幸存”。这在无状态计算集群中使大部分资源保持活跃是有意义的。但在 SAP HANA 中，表绑定到特定的存储分区和服务实例。其他分区中的表将无法访问，并且应用程序通常内部使用 – 机密无法继续，因为某些表无法访问。因此，SAP HANA 让初始 master 继续。 hdbnsutil hdbnsutil 可执行文件支持的一些操作在系统停止时访问持久性。为避免意外的活动或恢复服务导致数据损坏，该程序还使用基于网络和存储的心跳检查活动名称服务器，并使用防护设置 SCSI-3 持久保留。 SAN 存储：停止 hdbnsutil（或名称服务器）后，有意不释放 SCSI-3 持久保留。这确保没有其他服务无意中访问持久性，例如在脑裂情况后仍在其他主机上运行的服务。

故障检测涉及多个看门狗、重试和超时。根据故障情况，检测时间会有所不同，例如：
● SAP HANA 实例终止或主机关闭 检查主机会立即从操作系统层获取错误，通常会在不到一分钟的时间内检测到故障。
● 网络拆分
1.检查主机必须等到网络超时，因此故障检测通常需要 3 到 6 分钟。可以减少超时，但不建议这样做，因为它不允许从短暂的网络中断中恢复，或者在系统负载较重的情况下可能导致错误的故障转移决策，此时 ping 可能需要更长时间。
2.故障转移执行故障转移时间与SAP HANA启动所需的时间相当，因为备用主机上的服务最初是启动的，但运行是空闲的。在故障转移期间，它们执行与常规服务启动相同的初始化和持久性负载。