942
技術社區[雲棲]
阿裏雲上SAP高可用配置
1．部署架構
比較典型的SAP應用是搭建在小型機UNIX係統上的，小型機都有廠家提供的HA軟件，比如IBM的PowerHA。這樣的方案也是被SAP認證通過的。目前，SUSE LINUX也是被SAP認證通過的，但是在雲上，尤其是HA的方案，還沒有完全成型，本文檔重點探索的就是如何在阿裏雲ECS Linux環境搭建一套可行的HA方案提供給SAP係統使用。
我們以SAP AFS（Apprarel and Footwear Solution），即SAP在服裝鞋帽行業的解決方案為例，來搭建在阿裏雲ECS上的HA。
上圖中是SAP實例的官方部署建議圖，基礎軟件環境的安裝和部署情況：
阿裏雲SUSE Linux 11 SP3 + SAP ECC 6.0 EHP6 + SAP NetWeaver 7.3.1 + Sybase 15.7。
上麵的架構圖中沒有體現DB，我們必須把DB也考慮進來。同時，根據SAP應用的特點，我們在部署上也做了一些改變，最重要的就是將SAPSID部署在了一個能多節點同時掛載和讀寫的存儲上，避免了在兩個節點做切換的過程，提升係統的可用性。
節點A部署的有：阿裏雲SUSE Linux + ASCS + SAP primary Application Server；
節點B部署的有：阿裏雲SUSE Linux + DB + SAP Secondary Application Server。
在這個架構中，application Server在ASCS後端，ASCS提供客戶端的統一訪問，然後分發到後端的application Server。所以，我們發現整個架構存在2個單點，一個是DB，一個是ASCS。HA的目標就是解決這兩個單點，在發生故障時能夠進行切換，保證係統整體的高可用性。
2. 方案評估
我們在兩個方案上做了評估和選擇，一個方案是與SUSE Linux配合緊密的HAE（High Availability Extension），另一個是開源的keepalived。
2.1 HAE介紹
HAE的層次結構主要有：信息交換/基礎結構、資源分配和資源層。第一層和第二層基本是HAE自己控製和管理的，主要用來協調基礎信息，集群配置，控製上層資源等。對用戶來說，可以配置最多的一層在最上層，即資源代理（resource agent）。資源代理是已寫入的用來啟動、停止和監視某種服務（資源）的程序（通常是外殼腳本）。資源代理僅由 LRM 調用。第三方可將他們自己的代理放在文件係統中定義的位置，這樣就為各自的軟件提供了現成群集集成。目前，HAE已經集成了適用於市麵上大多數主流應用和軟件的資源代理，包括mysql、lvm、oracle等，包括SAPDatabase和SAPInstance也是已經包裝好的資源代理。
經測試，SAPDatabase可以正常管理本測試中用到的sybase 15.7，但是SAPInstance代理由於我們的部署架構將一個實例在兩個節點進行了拆分，所以無法被管理。在嚐試完全重寫對ASCS的資源代理時，由於對ASCS的原理理解不夠深入，在規定的時間內沒能調整好腳本到預期的狀態，所以最終暫時放棄了HAE方案。
理論上說，HAE是比較成熟的商業軟件，提供圖形化的配置運維管理界麵，降低了對客戶的技術要求，而且還有軟件廠家的售後服務。如果可能，還是會建議客戶首選HAE。
2.2 Keepalived介紹
Keepalived 是一個基於VRRP協議來實現的LVS服務高可用方案，可以利用其來避免單點故障。一個LVS服務會有多台服務器運行Keepalived，一台為主服務器（MASTER），其他為備份服務器（BACKUP），這些服務器是通過優先級來選舉出來最高優先級的那個節點為主服務器的。這些節點對外表現為一個虛擬IP，主服務器會發送特定的消息給備份服務器，當備份服務器收不到這個消息的時候，即主服務器宕機的時候， 備份服務器就會接管虛擬IP，繼續提供服務，從而保證了高可用性。
在實際測試過程中，發現keepalived的配置，尤其是對腳本的控製比較簡單直接，容易理解，也好上手，最終也及時地完成了測試和客戶需求。所以我們以keepalived為例來說明在阿裏雲上如何配置對SAP的HA。
3. 實施過程
所有的HA都要滿足以下幾點，在阿裏雲上實現也不能例外：
n VIP：為需要做高可用保證的應用服務提供統一的對外IP，能在集群中節點進行漂移和切換；
n 共享存儲，上麵部署共享的數據，提供在主節點down掉後，備節點可以掛載的可能性；
n 異常/故障狀態下的處理機製實現。
我們在下麵的實施步驟中重點說明和解決這幾個問題，我們會創建兩個VRRP_INSTANCE，分別管理DB和ASCS。
3.1 VIP的創建
阿裏雲提供一款叫HaVIP的產品，可以幫助客戶在指定的VPC網絡內創建最多5個能夠在該CIDR網段內沒有被占用的VIP。客戶可以通過提工單的形式申請HAVIP，申請成功後，在VPC的配置界麵將出來一個新的菜單：“高可用虛擬IP”。
根據提示選擇交換機，創建2個IP，一個IP是172.16.32.30，這個是DB的VIP；一個IP是172.16.32.40，這是ASCS的VIP。這兩個IP創建出來先預留，不要使用。
如果您很不幸沒有申請到havip，也不要沮喪，還有一款開源軟件：n2n VPN可以解決雲上的虛擬網卡和多IP的問題。可以移步這個地址來參考實現：https://blog.csdn.net/yetyongjin/article/details/7419894。
3.2 共享存儲
阿裏雲在2017年4月即將推出共享的塊存儲，即SSD雲盤。在正式推出前，我們在阿裏雲上暫時隻能使用開源的iscsi來實現共享。在安裝配置共享存儲前，我們需要熟悉一下iscsi的相關概念，比如iscsi-target和iscsi-initiator，在我們的規劃中，我們使用了4台target，每台target上掛載一個800GB的SSD雲盤。配置HA的2個節點自然就是iscsi-initiator了。
目前主流的linux發行版都已經自帶了iscsi，阿裏雲上的suse linux、centOS也不例外，安裝一下就好了。
在SUSE Linux 11SP3的版本中，配置iscsi-target的步驟：
（1） 打開yast，選擇Network-Service-iSCSI Target，係統會提示沒有安裝，選擇安裝，稍等一會兒就安裝好了；
（2） 安裝完後，就可以退出yast了，如果繼續用yast來做配置，會發現後麵共享出去的磁盤是沒有辦法被識別的；
（3） 此時，需要編輯一下/etc/ietd.conf文件，這個文件的格式大約是：
這裏的關鍵是第二行的Path和Type，Path定義了我們要共享的本地磁盤路徑，Type定義了共享磁盤的類型。
（4） 然後就可以執行#service iscsitarget start啟動iscsi-target了；
（5） 每個iscsi-target上都做一番這樣的配置；
（6） 在兩個HA節點上，打開yast，選擇Network-Service-iSCSI Initiator，按照提示安裝；
（7） 安裝完畢，在Conneted Targets界麵選擇Add添加
（8） 填上iscsi-target的IP地址去發現共享出來的磁盤，參照下圖
（9） 然後NEXT，然後再添加，直到把所有的target都添加進來。此時fdisk -l和lsscsi都能看到新掛載的磁盤，保證2個節點都能看到；
（10） 在任意一個節點，使用lvm可以創建vg/lv/fs，將這些資源分配和掛載給需要的節點使用。這裏我們創建了兩個vg:sapvg和datavg。sapvg存放ASCS數據，掛載了3個目錄：/export/sapmnt、/export/usr/sap/trans和/usr/sap/TST/ASCS10，默認在節點1；datavg存放數據庫數據，掛載了1個目錄：/sybase，默認在節點2。
3.3 NAS
NAS還要求能給兩個節點提供一個可以同時掛載並發讀寫的2個文件係統，最初使用的NFS，將一個節點的本地目錄共享給另一個節點，在實際使用中發現當服務節點異常時，使用NFS共享目錄的節點會受到很大的影響。比如NFS Server已經掛掉了，那麼client節點因為無法正常umount NFS目錄會導致涉及到NFS目錄的所有操作都長時間hang住。
於是，我們更換了一個方案，將阿裏雲的NAS引入了方案中。實踐發現，NAS作為性能要求不高的共享文件係統是十分合適的，也非常穩定。
所以，兩個節點都掛載了2個NAS文件係統：
112f4483d9-byb70.cn-beijing.nas.aliyuncs.com:/ /sapmnt
1f8dc4b72a-yaq0.cn-beijing.nas.aliyuncs.com:/ /usr/sap/trans
3.4 部署SAP
這部分不是本文的重點，按照第一章的設計將SAP AFS部署好即可。前提是先把HAVIP對應的存儲資源、NAS共享文件係統都準備好。
3.5 部署HA
（1）下載keepalived
我們希望盡可能下載使用最新版本，但是在實際中發現SUSE 11 SP3和keepalived的兼容性還是存在比較嚴重的問題的。經過反複測試，我們選用了1.2.20版本。
下載地址：https://www.keepalived.org/download.html
（2）安裝keepalived前的準備
可能還需要升級openssl，依然是去網上找openssl 1.1.0e的包，自己make和make install安裝。這裏可能還有其他的包需要安裝，在安裝keepalived時會進行檢查，如果不通過，就回到這一步來補齊。
（3）安裝keepalived
（4）配置keepalived
請注意，keepalived安裝完後，會自動生成一個配置文件：/usr/local/keepalived/etc/keepalived/keepalived.conf。修改這個文件是沒有意義的，因為keepalived認可的配置文件是：/etc/keepalived/keepalived.conf！！！
在正式進行配置之前，請務必先保證手工執行腳本能完美實現對vrrp實例資源的完整管理和切換，如果手工執行都無法正常運行，那麼加上HA自動化後將會有更多不可預知的情況發生！！！
當你已經確定手工執行腳本已經沒有任何問題，就可以配置keepalived了。2個節點（afsdev01和afsdev02）都得配置，修改完成後，我們的節點1配置文件長這樣子：
節點2配置文件長這樣子：
這兩個配置文件定義了兩個vrrp實例，實例中的節點優先級，VIP資源，實例在成為master時執行的腳本，在成為backup時執行的腳本。
特別提醒一點，正常VRRP協議是要通過組播來實現的，阿裏雲對ECS網絡禁用了組播，所以我們需要使用點對點的模式，即“unicast”方式。
這裏我們定義希望master節點選舉出來後，就遠程到對端把服務下掉，然後在自己的節點啟動服務。相應的腳本：
init_master.sh
init_db_master.sh
sap_start.sh
sap_stop.sh
db_start.sh
db_stop.sh
如果希望HA的管理更精細，我們還可以加入track_script，定義一段狀態判斷的腳本，比如定義每個幾秒判斷某個進程是否存在，如果存在就返回正常，不存在就返回異常，異常時將該節點的優先級調低多少點，從而導致主節點的優先級低於其他備節點，重新選舉出一個新的主節點來，最終實現了instance的切換。
3.6 其他的配合工作
為了能讓係統在重啟後也能支持SAP實例的正常工作，我們還需要增加一些啟動項，比如自動掛載NAS目錄，修改一些目錄和文件的權限，以免在vg的切換過程中發生異常。
#vi /etc/init.d/after.local，內容：
3.7 啟動keepalived
當確認配置和腳本都沒有問題，就可以在兩個節點分別啟動keepalived了。
執行：# /usr/local/keepalived/sbin/keepalived
會看到有幾個進程啟動：
然後觀察keepalived的日誌文件，默認為：/var/log/messages，能看到這樣的記錄，代表這keepalived啟動。
緊接著能看到的提示，這意味著對於VRRP_Instance(db)來說，本節點被選舉為主節點，並執行主節點定義的腳本：
然後，需要去腳本定義的日誌文件查看，我們所執行的動作是否執行成功。
3.8 測試keepalived
在我們配置的keepalived中，支持兩類失敗的資源切換：keepalived高可用程序失敗和ECS節點失敗。
測試過程：
（1） 確認該節點的資源和keepalived運行正常；
（2） 強製shutdown該節點或殺掉keepalived進程；
（3） 觀察另外一個節點該原來運行在對端節點的一係列資源接管過來，恢複在短暫中斷後自動恢複，切換時間在15秒到120秒不等。這個切換速度與小型機的環境相當；
（4） 重新啟動被關閉的節點，重新運行keepalived；
（5） 觀察重新啟動的節點在數秒內接管回來自己的資源。
如果我們定義了對異常狀態的檢測，我們可以再加入異常狀態的場景測試內容。
同時，由於阿裏雲ECS底層物理網卡做了bond，加上物理機NC的自動化運維和故障熱遷移等都由阿裏雲負責，所以在雲下要考慮的一種場景，即網絡或網卡故障的情形是可以不用考慮的。當然，有一種例外，即有人執行了#fconfig eth0 down，這會造成腦裂（brain-split），要解決這種異常，也需要在keepalived的配置中加入另一種track_script，即每隔一段時間ping一下網關地址，如果連續多次沒有正常返回，那麼就認為自己已經異常，執行一個腳本把自己的keepalived服務和係統的SAP服務一起殺掉，避免腦裂的發生。這些配置都與雲下使用keepalived是相同的，不再單獨做實現和測試了。
最後更新：2017-05-15 17:03:05