Leo Yeh's Blog

SAS Viya (102)

教學目標

初步了解升級 SAS Viya 平台的基本概念。

重點概念

首先最近這幾年主要幫金融產業和製造產業的客戶在 Red Hat Linux 7 作業系統上部署 SAS Viya 平台,更進一步完成將 SAS Viya 3.3 平台升級至 SAS Viya 3.4 平台,其中一家部署 Co-located Hadoop 的分散式架構,另一家則是部署 Remote Hadoop 的分散式架構,這兩者差別主要在於前者是將 SAS Viya 平台在與 Hadoop 平台安裝在一起,後者是不將 SAS Viya 平台在與 Hadoop 平台安裝在一起,根據企業的需求會採用適當的部署架構,而此篇文章主要就是分享升級 SAS Viya 平台的心得,值得一提的是 SAS Viya 平台目前已經能夠直接在同一台伺服器透過自動化腳本進行原機升級作業,並且不會刪除 SAS Viya 平台中的資料、內容、使用者、權限設定、… 等設定項目,至於詳細升級步驟請參官方文件。但是客戶為何要升級呢?升級主要會為已經部署的軟體增加或改善重要的功能,如果要執行升級,則建議需要一個新的軟體訂單來升級已部署的軟體,升級時可能會需要變更已部署軟體的設定,請注意在升級 SAS Viya 軟體需要中斷服務的時間,並且在升級過程中,我們必須先停止所有 SAS Viya 服務,以及在開始升級之前,建議先進行快照或備份,以及匯出關鍵報表內容的 json 檔和記錄關鍵 caslib 連線資訊,以防意外情況發生能夠進行還原,以及透過 SAS Environment Manager 手動刪除「Default Backup Schedule Job」,否則升級完成之後會出現備份的問題,需要手動調整。此外升級過程中經常會遇到問題,此時就會需要進行故障排除,其中最常遇到就是 執行 Ansible 自動化腳本時發生錯誤、HDFS 無法正常載入資料至記憶體中、SAS Viya 平台的系統報表無法顯示、 SAS Viya 服務無法正常執行、… 等。

接著升級過程中難免會發現 SAS Viya 服務無法正常執行,此時請重新確認 「inventory.ini」和「vars.yml」設定檔,並且停止所有 SAS Viya 服務之後,重新執行 Ansible 自動化腳本進行部署,設定檔的詳細資訊,請參考官方文件,以及建議服務停止完成再執行「ps aux | grep sas」和「ps aux | grep cas」確認服務皆已經關閉,尤其是 PostgreSQL 和 RabbitMQ 經常會沒有正常關閉,而導致執行 Ansible 自動化腳本發生錯誤,或者執行 Ansible 自動化腳本時 Consul 服務可能會無法正常被啟動,此時需手動先啟動 Consul 服務,才能夠正常取得客戶端 Token, 以利後續進行自動化設定部署。此外當升級完成之後「/var/log/sas/viya」的軟連結會被自動刪除,此時我們需要執行「ln -s /opt/sas/viya/config/var/log /var/log/sas/viya」指令手動建立軟連結,以利進行故障排除,請注意此目錄不能夠隨意刪除,若不小心刪除了「/opt/sas/viya/config/var/log」目錄中所有的檔案,就算重新執行 Ansible 自動化腳本也不會自動建立「/opt/sas/viya/config/var/log/compsrv/default」目錄,此時將會導致無法正常登入 SAS StudioV ,並且啟動 Compute Server 進行操作,為了解決無法啟動 Compute Server 的問題,我們僅需要手動建立「/opt/sas/viya/config/var/log/compsrv/default」目錄,並且執行「/etc/init.d/sas-viya-compute-default restart」重新啟動 Compute Server 服務就能解決此問題 ,以及不會自動建立「/opt/sas/viya/config/var/log/evmsvrops/evdm/defualt」目錄,此時就會導致 SAS Environment Manager 無法正常產生所有與系統相關的報表資料,並且當我們執行「/viya/home/bin/sas-ops validate —level 3 —verbose」指令針對 SAS Viya 的營運架構進行驗證將會出現錯誤訊息,如下所示:

1
2
3
4
5
6
7
8
Validation test(s) completed with 7 error(s):
ERROR evdm step arm_load status is [Error]
ERROR evdm step audit status is [Error]
ERROR evdm step etl_driver status is [Error]
ERROR evdm step resetdm_cas status is [Error]
ERROR evdm step rolloff status is [Error]
ERROR evdm step update_inventory status is [Error]
ERROR evdm step ziptsv status is [Error]

為了解決此問題我們要先手動建立「/opt/sas/viya/config/var/log/evmsvrops/evdm/defualt」目錄,並且執行「/etc/init.d/sas-viya-stream-evdm-default restart」重新啟動 SAS Environment Manager DataMart 服務,並且執行以下指令之後,就能夠在 SAS Environment Manager 中查看所有與系統相關的報表資料。

1
2
3
4
5
6
7
8
9
10
11
$ /opt/sas/viya/home/bin/ops-dm-admin unlock -datamart evdm -force
$ /opt/sas/viya/home/bin/ops-dm-admin purgeall -datamart evdm -force
$ /opt/sas/viya/config/var/ cache/auditcli
$ /opt/sas/viya/home/bin/ev-genaudit -a reports,folders,dataPlans,casManagement,casAccessManagement,--user-id -l 1000 -d 7 -v
$ /opt/sas/viya/home/bin/ops-runsas --pgm audit.sas --datamart evdm -set SAS_AUDIT_CSV_FILE /opt/sas/viya/config/var/cache/auditcli/audit.csv -set SAS_AUDIT_TABLE_NAME AUDIT -set SAS_CLI_DEFAULT_CASLIB SystemData
$ /opt/sas/viya/home/bin/ops-runsas --pgm arm_load.sas --datamart evdm
$ /opt/sas/viya/home/bin/ops-runsas --pgm resetdm_cas.sas --datamart evdm
$ /opt/sas/viya/home/bin/ops-runsas --pgm rolloff.sas --datamart evdm
$ /opt/sas/viya/home/bin/ops-runsas --pgm update_inventory.sas --datamart evdm
$ /opt/sas/viya/home/bin/ops-runsas --pgm ziptsv.sas --datamart evdm
$ /viya/home/bin/sas-ops validate --level 3 --verbose

再來當我們升級完成之後,無法正常連線至 Hadoop 存取 HDFS 中的資料時,請重複確認「inventory.ini」和「vars.yml」設定檔是否正確,以及確認是否已經將「SAS Plug-ins for Hadoop」的相關檔案是否已經按照官方文件放置適當的目錄中,並且設定正確的執行權限,以及必須確認 HDFS 所有節點是否皆有重新啟動。除此之外,還必須確認 CAS Controller 伺服器是否能夠以無密碼 ssh 的方式以 cas 帳號登入至 Hadoop 的 Namenode 伺服器中,若是無法正常登入,請確認使用者的 SSH 公開金鑰是否設定「chmod 600 ~/.ssh/authorized_keys」的權限,若是沒有確認這部份,將會導致當我們透過 SAS Environment Manager 手動將 HDFS 資料館中的資料檔載入至記憶體中時,一直發生「ERROR: The HDFS file is missing blocks of data.」的錯誤訊息,此外若是使用者需要登入 SAS Studio 執行 PROC CASUTIL 將 HDFS 資料館中的資料檔載入至記憶體中時,也必須確認確認 CAS Controller 伺服器是否能夠以無密碼 ssh 的方式以該使用者帳號登入至 Hadoop 的 Namenode 伺服器中。

最後當升級 SAS Viya 3.4 平台完成之後,我們還需要必須確認是否有針對 SAS 預設資料館,設定 sasapp 存取控制權限,像是 AppData 、 SystemData 、 Samples 、 Models 、 VAModels 、 ReferenceData 、 search 、… 等,我們主要會手動執行以下指令自動設定 sasapp 存取 SAS 預設資料館的控制權限。此外我們也可能需要通知使用者清除網站瀏覽器的快取之後,再重新登入 SAS Viya 平台,以及將網站瀏覽器書籤中 SASHome 連結更改為 SASDrive 連結,這非常重要,否則當使用者嘗試使用 SAS Viya 平台時將會出現無法正常使用的錯誤訊息囉!請注意,當使用者操作幾天突然就無法正常使用時,請先確認憑證是否到期,因為 SAS Viya 3.2 至 SAS Viya 3.4 的預設自簽伺服器憑證目前皆是一年,而當伺服器憑證過期時,將會導致 SAS Viya 平台本來正常使用卻突然無法正常使用的情況發生,至於如何更新 SAS Viya 平台的伺服器憑證,請參考官方文件

1
$ /opt/sas/viya/home/share/deployment/add_new_caslib_controls.sh --sas-endpoint "https://viya.server.com.tw:443"

總結根據升級 SAS Viya 3.4 的經驗,通常需要花費一週的時間,其中有一半以上的時間主要是進行故障排除,因為已經上線的 SAS Viya 平台通常需要升級時皆是已經有許多功能異常,以及進行許多變更作業導致許多升級過程中未被告知的設定,將很有可能會導致升級完成之後發生異常狀況,此時面對異常狀況,我們就會需要非常熟悉 SAS Viya 平台最底層與作業系統運作的方式和原理,才有可能找出根本原因解決問題,因此升級作業通常是一項非常具有挑戰的工作任務。

相關資源

⬅️ Go back