在實際的生產環境中, SAP HANA的分散式系統很常見, 因為隨著資料量的擴充, 通常單機SAP HANA往往記憶體會越來越吃緊,所以有必要搭建分散式系統, 從而分散查詢壓力, 保持SAP HANA的高速性. 在另一方面, 在實際生產環境, 為了防止單機故障, 通常也會做HA, 以便當某個結點主機宕機之後系統能夠保持穩定.

以上便上SAP HANA分散式系統及高可用性的實際需要, 但是受限於測試條件, 需要多臺SAP HANA伺服器, 一般大家都沒有自己動手搭建過分散式HANA, 大部分都是在單機上做測試. 但是SAP HANA的分散式系統與我們平常印象中的分散式系統稍微有點不一樣

一 有關分散式的基本概念

\

Host

一個主機指SAP HANA資料庫的執行的作業系統環境, 可以對應一臺物理機器.

Instance

例項, 是指在作業系統上安裝的SAP HANA的編號, 所以可以在同一個主機(Host)上安裝多個Instance是可以的, 對於多主機的SAP HANA 系統, 要求各個主機上的例項號都相同.

System

一個SAP HANA系統是指同一編號下的多個例項的集合, 是一個整體.

對於單主機系統的SAP HANA, 想必大家都很熟悉了, 以下簡單介紹一下多主機的

多主機系統的構架如上圖所示.

如上圖表示的SAP HANA系統例項號為01, 由三臺主機構成hana1, hana2, hana3 , 這三臺主機共享享儲存系統Storage Solution. 所以,前文筆者提到, SAP HANA中的分散式系統主要是指記憶體的分散式, 比如這裡記憶體分佈於hana1, hana2, hana3. 但是這三臺主機共享同一個儲存系統, 資料檔案並沒有分佈. 所以第一個問題就是, 那這個共享的儲存系統要是壞了怎麼辦 ? 答案簡單明瞭, 如果真這樣, 那麼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效能不太好, 在實際生產環境並不推薦.

GPFS:

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的基礎, 故在此先做了一些基本的介紹, 在後續文章中將具體介紹如何搭建分散式系統.