SAP HANA 高可用度與擴充性 Part 1
這一篇我們來介紹SAP HANA高可用度(High Availability) 及 擴充性(Scalability)
一般IT系統的運作針對高可用度我們會分為兩類，預期性與非預期性。預期性就如同大家知道的IT系統的軟硬體升級維修等等日常作業。非預期性就是軟硬體無預警的跨調，甚至是地端機房電力/水／火災等等問題。所以建立系統的高可用度就非常重要。
一般這種兩個指標可以參考，就是RPO and RTO。這兩種指標會根據每個公司的要求不同而有所差異。關於這兩種指標的詳細描述有興趣的讀者可以參考網路上其他資料。以下簡圖可簡易解釋這種兩指標
哪甚麼是高可用度？底下一些術語及其描述可共參考
哪HANA在高可用方面有哪些supports呢？
- 準備階段: 定期備份以及有第二套系統存在於同個機房或不同機房
- 偵測階段: 能夠＂快速且正確＂的偵測有問題發
- 回復階段: 開始將資料與系統服務於可用的系統上恢復
- 服務逐漸正常階段: 服務開始逐步正常
- 若最後原始的軟硬體修復就可將服務轉回原系統，但需要有更多的測試與確認。當然這個也可以是非必選項，取決於每間公司的政策。
SAP HANA有 Fault recover and Disaster recovery，如下圖
上圖中，Fault recovery的第一項是HANA中的Servic restart（HANA有watchdog系統）.這個重啟很快RPO/RTO大都不會很有因為重啟特定服務只會重新載入該項服務的data進到memory，但若是整個HANA系統重啟哪RTO就要花費很多時間了。至於為什麼會花時間可以參考其他HANA的篇章。最後是主機的failover，花費的時間不會比System restart還要多。不過最後還是要說這一切取決於我們的硬體，效能越好當然開機時間越快。但也與整體架構設計有關。Disaster Recovery就比較多樣了，另外System Replication後面會提及。
而storage replication則是經過storage哪一個layer直接做replication(就是一般大家使用storage replication的solution一樣，只是這個storage要經過SAP認證過）但這個方案有丟失資料的可能性。如果是跨地端機房實行storage replication, SAP建議兩地的距離要在100公里內。
Fault Recovery
我們來看一下整個HANA在OS中的開機流程（這個需要對Linux系統面有稍微的了解）就可以知道為什麼HANA可以驅動OS執行Services or System restart
關於Linux的部分在此不提了，我們看到在經過一連串的服務啟動後”sapstartsrv”會去讀取相關的參數檔(profile)啟動一連串前端的服務（Web Service)跟啟動”sapstart”這個服務也會去讀取profile並啟動HDB daemon服務。
所以我們可以比對cockpit 的Process ID於OS中的PID是相同的
另外在scale out的架構下，主機的 Auto failover是需要有備用機的（如下圖），在這個架構下standby Host是沒有任何資料也不接受任何服務要求的。而有問題的主機一但被修復後可以重新加入這個群組內變為standby的主機。
接下來我們來看一下scale up and scale out的高可用度有甚麼不同
一般我們會使用scale out的架構無非是為了突破hardware/OS的極限，以達成效能與資料的擴增（不過hana的架構是需要shared storage不管是NAS or SAN).哪如果是scale up的HA會使用到system replication而scale out通常都會有備用機（如上圖）否則你的scale out架構就沒有ＨＡ的功能了。相對system/services recovery來說 scale out就會比較快。
scale up 的效能就是取決於該台的機器效能，但scale out就會有很多參數可以設定。因為你可能不是每台主機的規格大小一樣，有時可能會用到既有設備與新設備混和。所以每台的處理能能力可能不同。在更進一步講述HANA的HA之前我們要來稍微解釋一下在scale out的架構下table的分散模式。
Table Partitioning
如下圖，我們可以將table 分散到各個主機處理，例如依日期分配（可能是年份在table某個欄位有記載年份）或是地點。懶一點的話可以用hash的方式（但需要有某個欄位加料進去）
根據這樣的方式table partitioning有幾個好處
- 分散負載，如同時讀取大量資料
- column table的size可以被限制，單台主機每個column最多能處裡20億筆資料，也就是說如果你是scale up架構只能到這個極限。
- 利用多主機的多個CPU同時處理資料
- 因為多主機分散資料，我可以讀取我只想要的資料（針對某些主機）
- 因為多主機所以Delta merge的效果更好（有關Delta Merge可參考其他篇章）
哪Best Practices是甚麼呢？
- 每個partation 的資料筆數不要超過 1–2億筆
- 每個table的partation "最好"不要超過八個
- 若你有某個column會經常用來做 SQL “Where”的篩選，哪你應該用這個當作range partition的主要區分
- 經常會用到join的同一個table schema與你在使oin多個column時會用到 "ON"語法的都應該要做partation
以上都是SAP文件中建議的最佳實踐，但這也只是建議。若要不遵守這個建議當然也可以，就是用更大更多的CPU/Memory/HDD/網路卡來撐。
在cockpit的table redistribution的規則如下
回到高可用度的議題，雖然有table partation的功能，但實際上整個scale out的架構還是需要一個共同的storage在儲存這些連續的資料。所以每一個主機的table最後還是寫回這一個storage上每台主機上實際只有HANA的Application。相關的設定檔與資料都在shared storage上每台主機只有運算的功能存在(PS這一點跟Google cloud的OLAP服務- Bigquery不一樣，在Big Query所有的主機節點都是獨立的,沒有這種shared storage的元件存在)。
另外可能這一個HANA system服務了多個重要的Application，可能會依重要程度分級，這時你也可以把這一群主機分群不同的standby host 給不同的Application. standby的Host可以有多台。
雖然如上圖有分host group,但是其實在是共用資源。例如Group HA1 standby host已經被用掉了，而HA2還沒有而這時HA1不幸的有又一台Host掛掉，這時HANA會把HA2 的syandby host拿給HA1 來使用。而同一個group的Host機器規格大小建議要一樣也要在同一個機房內。
上面提到的Master/Slave node是一般的標準做法，但當前端使用到SAP Business Warehouse我們有時候可能需要將資料分級。可能分成常用或不常用的，稱作Extension Group。
不是經常使用的(可能一天一次)的資料就可以分級放在Extension node上(這是將Slave Node指定成Extension node)
若後面要加入新的HOST,可以使用HDBLCM 或cockpit來加入，另外不論新增或移除HSOT，都需要重新檢視你的Backup/Recovery Plan.
新的HOST再加入這個scale out的架構前有一些事前準備工作
- HANA software已經被安裝到主機裡(包含在shared storage的相關檔案
- 要有相同的路徑與SID(如multi host的圖示)
- 這一個要加入新主機的HANA System之前有安裝 database lifecycle manager)
- 新主機與其他主機的時間差不能超過180秒(意思是你的NTP server與 HOST的連線很重要)
底下範例，當host 2掛掉後。standby host就會去讀取host 2在shared storage的資料並把資料載入memory開始運作
上圖我們可以看到在scale out的架構中有分Master and Slave的主機，這兩種role 的Host在fail時會不一樣。 slave host在fail時 standby host會接手，但若沒有特別設定當Master host fail, Slave host會去接手 Master 的工作而standby host會去接手slave host,這個樣子failover的時間就會拖長因為你會有兩次的failover。
為了避免這種狀況就必須指定當Master host fail時還是由standby host去接手
簡介備援(Disaster Recovery) 的三種對應
基本上這是要在另一個DataCenter對應的災難復原，你可以把這三種方式看作是在另一個DR site的Hot site / Warm site / Cold site(PS 這是屬於BCP- Business Continuity Plan中的 DRP — Disaster Recovery Plan 有興趣的人可以去搜尋相關文件)
Backup: Cold site
只有另一個機房只有備份其他甚麼都沒有，最省錢但重建整個系統最耗時
Storage Replication: Warm Site
花的錢比backup多，重建系統的時間比backup短。因為你已經有部分的硬體設備了。
System Replication : Hot Site
最花錢因為要兩套一模一樣的設備，但服務回復最快。且在DR site的機器不可以拿來給其他的環境(像是Dev/QA環境使用)。但可以用來做報表讀取的來源。
