SAP HANA高可用性方案

说明

最近公司要上SAP HANA的项目所以进行了先行的研究,下面是一些简单的研究成果。

SAP HANA的高可用性方案分为三种,一种是使用内存分布式的部署,使用一台主节点,多台辅助节点,和一台或多台备用节点,一种是系统复制,还有一种基于分布式存储的解决方案。我们的方案使用的系统复制的方案。以下是三种方案的说明。

有关分布式的基本概念

在实际的生产环境中, SAP HANA的分布式系统很常见, 因为随着数据量的扩充, 通常单机SAP HANA往往内存会越来越吃紧,所以有必要搭建分布式系统, 从而分散查询压力, 保持SAP HANA的高速性. 在另一方面, 在实际生产环境, 为了防止单机故障, 通常也会做HA, 以便当某个结点主机宕机之后系统能够保持稳定.

以上便上SAP HANA分布式系统及高可用性的实际需要, 但是受限于测试条件, 需要多台SAP HANA服务器, 一般大家都没有自己动手搭建过分布式HANA, 大部分都是在单机上做测试. 但是SAP HANA的分布式系统与我们平常印象中的分布式系统稍微有点不一样, SAP HANA中的分布二字主要是指’内存’的分布式, 而不是指数据文件分布式.

《SAP HANA高可用性方案》

Host

一个主机指SAP HANA数据库的运行的操作系统环境, 可以对应一台物理机器.

Instance

实例, 是指在操作系统上安装的SAP HANA的编号, 所以可以在同一个主机(Host)上安装多个Instance是可以的, 对于多主机的SAP HANA 系统, 要求各个主机上的实例号都相同.

System

一个SAP HANA系统是指同一编号下的多个实例的集合, 是一个整体.

对于单主机系统的SAP HANA, 想必大家都很熟悉了, 以下简单介绍一下多主机的SAP HANA系统.

《SAP HANA高可用性方案》

多主机系统的构架如上图所示

如上图表示的SAP HANA系统实例号为01, 由三台主机构成hana1, hana2, hana3 , 这三台主机共享享存储系统Storage Solution. 所以,前文笔者提到, SAP HANA中的分布式系统主要是指内存的分布式, 比如这里内存分布于hana1, hana2, hana3. 但是这三台主机共享同一个存储系统, 数据文件并没有分布. 所以第一个问题就是, 那这个共享的存储系统要是坏了怎么办 ? 答案简单明了, 如果真这样, 那么SAP HANA系统的所以数据将丢失. 所以为了这个共享存储系统的稳定性, 需要做冗余磁盘阵列等措施来保障这个共享存储系统本身的高可靠性.

系统复制

《SAP HANA高可用性方案》

系统复制是指另一个概念. 主要用途还是为了实现HA. 对于原生的SAP HANA系统Primary  System , 利用软件跟硬件冗余, 建立一个Secondary  System. Primary System与Secondary System之间就不共享存储了, 而是独立存储, 但是二者的数据保持同步, 这样一般其中一个系统坏掉了, 可以用另一个系统顶上去. 有关复制系统的具体实现及使用, 后面会有具体介绍.

存储解决方案

对于多主机的SAP HANA系统, 前面提到, 是基于共享存储的解决方案的.但是具体有哪些解决方案呢. 当前包括的解决方案包括NFS, GPFS, Storage Connector API. 如果你需要搭建一个分布式的SAP HANA 系统, 建立共享存储系统是第一步需要做的. 下面分布介绍这几种方案.

NFS

NFS 即Network File System,  网络文件系统. 它是一个CS构架结构, 如下图所示. 有一台NFS服务器, 用来提供存储服务. 客户机上安装客户端, 然后建立网络映射, 之后可以像访问本地文件一样去访问远程文件. NFS最大的好处是配置起来比较方便简单, 比如你需要测试分布式SAP HANA, 用这种存储方案比其他两种要方便得多, 在后面将要介绍的实验中也是基于NFS搭建的SAP HANA分布式系统. 但是NFS性能不太好, 在实际生产环境并不推荐.

《SAP HANA高可用性方案》

GPFS

《SAP HANA高可用性方案》

图片来源: http://www.ibm.com/developerworks/cn/aix/library/au-gpfsplan/

GPFS是IBM的商用文件系统, 相对来说配置起来比较复杂, 一般需要由IBM的工程师来配置. GPFS与NFS不一样, 它并不是一个CS构架的存储系统. GPFS文件系统基本上由三层架构组成:磁盘,网络共享磁盘(NSD), GPFS 文件设备.

GPFS 系统具有高性能,跨平台,系统可扩展等优势, 但是作为IBM的商用文件系统,其安装与部署需要由IBM的工程师进行.

Storage Connector  API

有关Storage Connector API ,笔者了解得也不多, 好像需要专门的硬件支持,由SAP 的硬件合作伙伴一起开发. 通过Storage Connector API, 各主机之间可以不用共享存储, 有各自的存储空间, 通过Storageg Connector进行通信, 其结构如下图所示.

《SAP HANA高可用性方案》

由于共享存储系统是搭建分布式SAP HANA的基础, 故在此先做了一些基本的介绍。

  参考资料: http://www.ibm.com/developerworks/cn/aix/library/au-gpfsplan/

系统复制方案详解

SAP HANA “System Replication”容灾解决方案,可在同站点或两个异地站点进行”N+N”方式的 SAP HANA容灾,System Replication 方案支持同步和异步的数据同步模式。

System replication 方案对网络配置转换方案有三种,一种是基于 SUSE 集群的 HANA System replication 方案,另一种是基于 IP 地址重定向,最后一种是基于 DNS 重定向

基于 SUSE 集群的 HANA System replication 方案

《SAP HANA高可用性方案》

图2-3 System Replication 逻辑图

如上图所示,主生产站点的 Node1 与容灾站点的 Node2 建立”system replication”的同步功能,所有 Node1 服务器端的 DATA 和 LOG 数据会同步到 Node2服务器端,当 Node1 服务器 SAP HANA 故障,SAP HANA 管理平台会通过脚本把 Node1业务转换到 Node2 中,由于使用同步模式,Node1与 Node2 的数据会完全一致,保证数据不丢失。

《SAP HANA高可用性方案》

图2-4 System Replication 组网图

如图 2-3 所示,SUSE 集群 HA 模块支持 SAP HANA System replication 功能,通过 SUSE HA 集群的 HANA 代理实现对 SAP HANA 的 System replication 状态进行管理,当发现主 HANA 服务器出现故障情况,SUSE 的

HA集群会自动触发HANA System replication 的切换功能,实现HANA主备节点自动切换,让HANA 备节点接管业务,SUSE 集群提供统一的 VIP 接口连接,HANA 主备节点自动切换后,上层应用无需重新配置 HANA 连接 IP,实现一体化的高可用解决方案。

基于 IP 地址重定向

基于 IP 地址重定向方案和基于 DNS 重定向方案的 SAP HANA System replication 配置下无法实现自动切换功能,客户需要人工进行System replication 的主备切换功能,如果客户的主要 SAP HANA 系统与容灾 SAP HANA 系统都在一个二层交换网络内,可使用 IP 地址重定向方案,先通过 DNS 建立一个浮动虚拟 IP 地址,在二层交换机进行 IP 与 MAC 地址之间转换配置,当主 SAP HANA 系统故障后,可通过二层交换机进行配置,转换 IP 与 MAC 地址之间配置,指向容灾 SAP HANA 系统。如图 2-5 所示。

《SAP HANA高可用性方案》

图2-5 SAP HANA IP重定向图

基于 DNS 重定向

如果客户的组网是三层交换网络,可选用DNS重新向的方案,通过配置DNS的域名与IP地址的关系进行重定向,如图2-6所示,当主SAP HANA系统出现故障时,可通过脚本或手工对DNS服务器进行DNS配置修改,把SAP HANA系统的域名与IP地址进行转换配置,指向容灾SAP HANA系统的

IP地址,通过DNS重定向,无需重新配置客户端对SAP HANA服务器的配置。

《SAP HANA高可用性方案》
图2-6 SAP HANA DNS重定向图

转载自:https://blogs.sap.com/2014/09/17/sap-hana%E5%88%86%E5%B8%83%E5%BC%8F%E7%B3%BB%E7%BB%9F%E5%8F%8A%E9%AB%98%E5%8F%AF%E7%94%A8%E6%80%A7%E4%B8%80/

并参考’华为SAP HANA一体机技术白皮书(单机版) ‘做了修改。

点赞

发表评论