168大数据

标题: SAP HANA 高可用性 (High Availability) 解决方案 (二) – Host Auto-Failover, 节... [打印本页]

作者: 168主编 时间: 2017-5-24 19:20
标题: SAP HANA 高可用性 (High Availability) 解决方案 (二) – Host Auto-Failover, 节...

SAP HANA完全支持系统高可用性的要求，对从简单的单点故障的自动恢复到严重的数据中心灾难恢复，都有完整的解决方案。

下面我们先谈谈对使用影响相对较小的故障恢复，SAP HANA支持三种解决方案，为了应对从低到高的故障程度分别如下：

服务自动重启，当HANA的某些核心服务（如indexserver，nameserver等）出现故障停止后，它们会被自动重启，从而让使用恢复正常；此功能默认开启，对用户来说是透明的；
节点失效自动切换，这种方案要求HANA安装在多个节点上（至少两个），一个主（master）节点，若干个从（slave）节点，一个或多个备用（standby）节点；当主节点或者从节点发生单点故障时，备用节点能识别并自动从备用状态转到运行状态，从而代替失效的节点；
系统复制，需要创建备份系统（Secondary System），它会持续地从主系统（Primary System）同步数据和事务日志；由于主辅系统的镜像属性，一旦主系统出现灾难性的故障，我们就可以启用辅助系统来代替主系统；

此文着重谈谈节点失效自动切换方案，至于系统复制方案会在后续博文中会详细介绍。

安装

由于此方案需要HANA安装在多个节点上，我们先介绍一下安装方法（其实就是安装分布式HANA，关于HANA分布式系统的介绍可参考这篇博文：SAP HANA分布式系统及高可用性(一)

准备多个物理机器，为它们设置一致的用户名和密码，以及设置一个所有机器都能访问的共享存储空间；
在要做主节点的机器上，找到并运行hdblcmgui （在解压好的HANA安装包中）

3. 选择Install new system，然后Next >

4. 选择Multiple-Host System，输入共同的用户名密码以及在第一步中设置好的共享目录路径

5. 点Add Host…，输入第二个机器的主机名，选择此节点的角色，worker或者standby，然后点OK

6. 添加好需要的节点后，点Next >；就下图而论，HANA将会被安装在3个节点上，一主一从一备份

7. 输入System ID，Instance Number以及System Usage，然后点Next >

8. 输入Data Volumes 和 Log Volumes的存放路径

9. 输入System Administrator的密码

10. 输入SYSTEM的密码

11. 检查之前的输入信息无误后点Install开始安装

12. 安装成功后，可以在Landscape > Hosts里边看到如下信息

所谓的节点失效自动切换，就是说如果主从节点中的一个节点出现故障，导致其所有HANA 服务终止，备用的（standby）节点在侦测到故障后会自动转换为故障节点的角色，并接替它的工作。

下面两个图显示的是从节点（slave）出现故障，备用节点自动接替原来的从节点。

自动切换的原理与性能

下面我们通过一些测试来看看节点自动切换的性能。

首先要强调一点，备用节点在接管失效节点之前是不存储任何数据的。当主节点的name server检测到某节点失效后会选择一个备用节点去接替失效节点；备用节点的index server会从共享的目录中取得失效节点的相关database volumes并加载到内存中，而后最终完成接替失效节点的任务。

图一：备用节点接替前

图二：备用节点自动接替故障节点

为了应对主节点的故障，需要两个或以上的slave name server，如下图（按前文的安装步骤搭建三节点分布式HANA就会默认有两个slave name server），这两个节点均可作为master name server的候选接替节点，一旦当前主节点失效，两个候选节点中的一个会自动接替失效的主节点，被选中的候选节点会获取失效节点的database volumes以及其失效前的事务日志中，最后通过重启来完成接替任务。

另外，为了提高节点间的传输性能，一般来说需要在节点间建立内部高速网络连接（如光纤）。

当内部高速网络搭建好之后，需要在HANA的global.ini里维护相应的信息，首先是找到属性internal_hostname_resolution，添加相应的键值对—内部IP和节点的主机名，如下图所示。

然后就是找到属性listeninterface，把默认参数值改为.internal，修改后重启HANA。

下面的测试数据是基于以上网络设置的情况下测得的。

可以看出随着数据库的增长，切换耗时会随之变长。

在自动切换前数据库在磁盘中的大小 (G)	自动切换耗时（秒）
在自动切换前数据库在磁盘中的大小 (G)	主节点故障	从节点故障
5	71	41
10	77	42
100	93	63
200	119	81

客户端相应配置

为了使客户端在节点失效自动切换后能继续平稳工作，我们需要告诉客户端所有主节点的连接信息，包括当前主节点和其它所有能接替主节点的候选节点；通过下面的SQL语句可以获取所有符合条件的主机名：

SELECT host FROM sys.m_landscape_host_configuration WHERE nameserver_config_roleLIKE ‘MASTER%’ ORDER BY nameserver_config_role

下面的表格列出了几种常用的客户端适配节点失效自动切换机制后的连接示例，与单节点connect URL的唯一不同是需要标明所有主节点（包括候选节点）的连接信息，中间用分号隔开。

客户端类型	示例
JDBC	Connect URL: jdbc:sap://host1:30015;host2:30015;host3:30015/
SQLDBC	SQLDBC_Connection *conn = env.createConnection(); SQLDBC_Retcode rc = conn->connect(“host1:30015;host2:30015;host3:30015”, “”, “user”, “password”);
ODBC	Connect URL: “DRIVER=HDBODBC32;UID=userWD=password;SERVERNODE=host1:30015;host2:30015;host3:30015;”

如果连接串中的第一个节点失效而连接不上，客户端会尝试连接下一个节点，只有在所有标明的主节点都连接失败后才会抛出连接异常的错误。

总结

节点失效自动切换以增加冗余度（备用节点）的方式很好地解决了单点失效的问题；但是碰到整个数据中心机房级别的故障，也就是说所有节点都出现故障，这个方案就无能为力了；应对这中故障的方案就只能继续增加冗余度，用系统复制的策略在远端的另外一个机房构建一个与主（primary）系统完全同步的备份（Secondary）系统来解决，这个我们会在后续的博文深入讨论。

欢迎光临 168大数据 (http://www.bi168.cn/)