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

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

有关分布式的基本概念

/wp-content/uploads/2014/09/structofhana_542694.png\

Host

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

Instance

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

System

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

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

/wp-content/uploads/2014/09/multihosthana_542695.png

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

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


二 系统复制

system replication.png

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

存储解决方案

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

NFS

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

/wp-content/uploads/2014/09/nfsserver_542700.png

GPFS:

/wp-content/uploads/2014/09/gpfs_542701.png

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

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

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

Storage Connector  API

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

/wp-content/uploads/2014/09/connectorapi_542702.png

由于共享存储系统是搭建分布式SAP HANA的基础, 故在此先做了一些基本的介绍, 在后续文章中将具体介绍如何搭建分布式系统.

想获取更多SAP HANA学习资料或有任何疑问,请关注新浪微博@HANAGeek!我们欢迎你的加入!

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


转载请注明出处,

http://scn.sap.com/community/chinese/hana/blog/2014/09/17/sap-hana%E5%88%86%E5%B8%83%E5%BC%8F%E7%B3%BB%E7%BB%9F%E5%8F%8A…

请勿用于商业用途

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Tony Shen

    对于实际的SOH的生产环境的高可用方案, 目前主要 是采用一主一备的方式 , 那这两者这间是能过data replication 的方式多(不需要共享存贮)还是通过共享存贮的方式会比较多!能够给点建议吗?

    谢谢!

    (0) 

Leave a Reply