SAS 教學

SAS Viya (53)

教學目標

初步了解如何解決 SAS Viya 3.4 中 CAS 伺服器無法正常啟動的問題。

重點概念

首先當我們部署完成 SAS Viya 3.4 MPP 架構之後,主要會啟動 Cloud Analytics Services (CAS) 服務,以利進行分散式運算。此時可能會發生雖然 Ansible 工具部署 SAS Viya 3.4 正常完成沒有錯誤,但是以「sasboot」登入至「SAS Environment Manager」管理環境查看伺服器時,將會發現「cas-shared-default」的狀態為灰色無法進行操作,並且也無法進行資料的操作,因為無法選擇資料來源,以及無法正常查看授權產品資訊等情況發生,因此本篇文章主要就是要解決此問題。

接著我們先登入至所有 SAS Viya 伺服器,並且執行「ps aux|grep casluanch」指令確認是否每一台伺服器皆正常啟動 caslaunch 工具,若發現哪一台沒有正常啟動時,請執行「cat /etc/fstab」指令查看安裝 SAS Viya 的儲存空間是否被設定為「nosuid」,預設為「/opt/sas」,若是則請將「/opt/sas」複製至沒有設為「nosuid」的儲存空間,並且建立軟連結「/opt/sas」對應至沒有設為「nosuid」的儲存空間。

確認 caslaunch 是否正常執行

1
# ps aux|grep caslaunch

查看儲存空間是否為 nosuid

1
# cat /etc/fstab

建立對應的軟連結

1
2
3
# cp -Rp /opt/sas /sys/sas
# rm -rf /opt/sas
# ln -s /sys/sas /opt/sas

再來當我們設定完成之後我們在 SAS Viya 的「CAS Controller」伺服器執行「/etc/init.d/sas-viya-cascontroller-default restart」重新啟動 CAS 伺服器,其中包括「CAS Controller」和「CAS Worker」伺服器。至於執行相關記錄我們主要能夠查看 「/opt/sas/viya/config/var/log/cas/default」目錄中的「.log」和「.err」的記錄檔,像是若 CAS Worker 沒有正常啟動,則我們查看「caslaunchdefault_controller_daemon.log」記錄檔,則會發現「Node ‘‘ has not connected to the grid.」和「After 30 seconds nodes have not connected to the grid」的錯誤訊息。此外我們更能夠設定「/opt/sas/viya/config/etc/cas/default/logconfig.trace.xml」設定檔的記錄等級皆為「Trace」,以利查看更多執行詳細資訊,像是當我們設定記錄檔等級為「Trace」,並且重新啟動 CAS 伺服器之後,我們就能夠從「cas.log」記錄檔中查看所有 CAS 伺服器所執行「caslaunch」的完整指令,此時當我們將「caslaunch」的完整指令至對應的 CAS 伺服器執行時就能夠發現更多相關的錯誤訊息,像是以「cas」帳號執行完整指令,此時就會發現「UseHostToken specified in non-root launcher」的錯誤訊息。

重新啟動 CAS 伺服器

1
# /etc/init.d/sas-viya-cascontroller-default restart

查看 CAS 記錄檔

1
2
3
4
5
# cd /opt/sas/viya/config/var/log/cas/default
# ll -ltr
# vi cas_<yyyy-mm-dd>_<server>_<number>.log
# vi caslaunch_default_controller_daemon.log
# vi caslaunch_default_controller_daemon.err

設定 CAS 伺服器記錄檔等級

1
# vi/opt/sas/viya/config/etc/cas/default/logconfig.trace.xml

最後若還是有問題,則請設定 CAS 伺服器相關權限,透過權限的設定我們能夠了解 CAS 伺服器執行「caslaunch」工具主要是透過是以「cas」帳號 SSH 遠端無密碼連線至所有 CAS 伺服器,並且透過「root」帳號進行執行,所以若是部署的儲存空間設為「nosuid」將會導致無法正常執行。

設定 CAS 伺服器相關權限

1
2
3
4
5
6
# chown root:root /opt/sas/viya/home/SASFoundation/utilities/bin/caslaunch
# chmod u+s /opt/sas/viya/home/SASFoundation/utilities/bin/caslaunch
# chown cas:sas /opt/sas/viya/config/etc/cas/default/node.lua
# chown cas:sas /opt/sas/viya/config/etc/SASSecurityCertificateFramework/private/cas/shared/ -R
# chown cas:sas /opt/sas/viya/config/etc/SASSecurityCertificateFramework/tls/certs/cas/shared/default/ -R
# chown cas:sas /opt/sas/viya/config/etc/SASSecurityCertificateFramework/tokens/cas/shared/default/ -R

總結當我們部署 SAS Viya 3.4 時除了注意設定參數和網路連線之外,我們必須確認部署的儲存空間沒有設為「nosuid」,否則將會導致 CAS 伺服器無法正常啟動。

相關資源

SAS Viya (52)

教學目標

在 AWS 雲端平台中以 Kubernetes 容器叢集中部署 SAS Viya 3.4 平台的心得分享。

重點概念

首先我們在企業中部署 SAS Viya 3.4 平台,除了透過 Ansible 工具進行部署之外,當然我們還能夠透過 Docker 和 Kubernetes 進行部署。其中 Docker 部署的部份僅需要按照官方文件的步驟,就能夠順利完成,請注意 Docker 映像檔 (sas-viya-programming)、金鑰檔案 (license.sas) 和特定資料夾 (sasinside、sasdemo 和 cas) 是否已經建立就沒有太大的問題,當 Docker 部署完成之後僅能夠提供給程式設計師和資料科學家進行 SAS Studio 網站透過 SAS 程式碼完成機器學習的應用,至於能夠做到哪些機器學習的應用,請申請免費試用 SAS® ANALYTICS CLOUD 雲端服務,其中就有針對銀行資料進行機器學習演算法的分析應用教學。然而商業分析師和管理階層則會需要查看報表和更多視覺化非程式碼的業務需求等相關應用,此時僅以 Docker 部署是無法滿足業務需求,因此我們就需要透過 Kubernetes 進行完整部署,本篇主要則是針就以在 AWS 環境透過 kops 工具進行 SAS Viya 3.4 的叢集容器部署。

目前官方文件針對 Kubernetes 部署並沒有詳細步驟,僅有關鍵的重點概念,因此我們需要透過 SAS Software Github 上的 SAS Viya Container Recipes 進行部署,請先透過「git clone」指令下載至執行 Kubernetes 指令客戶端,若是以 AWS 雲端服務中的 EC2 伺服器為客戶端時,若發生「permission denied (publickey)」錯誤訊息,則需要將 EC2 伺服器中登入使用者的 SSH 連線公開金鑰檔「.ssh/id_rsa.pub」內容手動設定至登入的 Github 帳號中,若還是有問題則新增使用者執行「ssh-keygen」重新產生 SSH 連線公開金鑰檔試試。當我們下載 SAS Viya Container Recipes 相關檔案至「/sas-container-recipes」目錄之後,下一步我們必須準備 SAS Viya 3.4 的軟體信件取得 SAS_Viya_deployment_data.zip 檔案,並且上傳至「/sas-container-recipes」目錄中。

下載 SAS Viya Container Recipes 相關檔案

1
$ git clone git@github.com:sassoftware/sas-container-recipes.git

上傳 SAS_Viya_deployment_data.zip 檔案

1
$ cp /tmp/SAS_Viya_deployment_data.zip /sas-container-recipes

接著我們需要註冊 Docker Hub,主要會將建立的多個倉庫 上傳至 Docker Hub 中,當然我們必須安裝 Docker CE 工具才能夠透過腳本指令碼以 SAS_Viya_deployment_data.zip 建立多個倉庫,此時可能會遇到透過 ansible-container 自動化工具無法正常 Push 至 Docker Hub 倉庫的問題,此時我們僅需要修改「/sas-container-recipes/viya-visuals/viya-visuals-build.sh」腳本指令檔中的「ansible-container push —push-to docker-registry —username —password —tag ${SAS_DOCKER_TAG}」指令就能夠解決此問題。

安裝 Docker CE 工具

1
2
3
4
5
6
7
$ sudo su -
$ sudo yum install http://vault.centos.org/centos/7.3.1611/extras/x86_64/Packages/container-selinux-2.9-4.el7.noarch.rpm
$ sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
$ sudo yum install epel-release
$ sudo yum install docker-ce
$ systemctl restart docker
$ docker -v

建立多個倉庫

1
2
3
4
$ cd /sas-container-recipes
$ docker login
$ chmod +x build.sh
$ ./build.sh --type full --docker-registry-namespace <Docker Hub 使用者 ID>/sas-viya --docker-registry-url docker.io --zip SAS_Viya_deployment_data.zip

再來我們需要透過「aws」工具、「kops」工具和「kubectl」工具在 AWS 雲端環境中搭配 IAM、S3、Route53、EC2 和 ELB 服務建立符合 Kubernete 操作的環境平台。此時需要在 IAM 建立 kops 帳號,並且取得 Access Token 和 Access Token Secret 以利「aws」工具進行 AWS 服務相關資源的存取,並且在 S3 中建立 Bucket,同時設定 kops 帳號擁有存取的權限,以及購買與設定網域,透過 Route53 購買「.com」網域一年僅需12 美元,購買之後 Route53 就會自動註冊網域,但若是從 GoDaddy 其它網站購買網域,則需要手動設定網域,至於 EC2 則是透過「kops」工具自動進行建立,而 ELB 則是透過「kubectl」工具自動進行建立。

最後當 AWS 環境準備完成之後,我們就能夠按照以下步驟透過指令以 Kubernetes 容器叢集建立 SAS Viya MPP 的完整部署,主要步驟分別為:

  1. 登入 AWS 取得存取權限
  2. 安裝與測試 kops 工具
  3. 安裝與測試 kubectl 工具
  4. 建立 Kubernetes 容器叢集
  5. 更新 Kubernetes 容器叢集
  6. 驗證 Kubernetes 容器叢集
  7. 取得 Kubernetes 容器叢集中的 Node 狀態
  8. 建立 Kubernetes 容器叢集專用的 ELB 負載平衡服務
  9. 取得 Kubernetes 容器叢集中的 Services 狀態
  10. 取得 sasboot 管理者帳號的重設密碼之網站連結

登入 AWS 取得存取權限

1
$ aws configure

安裝與測試 kops 工具

1
2
3
4
$ wget https://github.com/kubernetes/kops/releases/download/1.10.0/kops-linux-amd64
$ chmod +x kops-linux-amd64
$ mv kops-linux-amd64 /usr/local/bin/kops
$ kops

安裝與測試 kubectl 工具

1
2
3
$ curl -o kubectl https://amazon-eks.s3-us-west-2.amazonaws.com/1.11.5/2018-12-06/bin/linux/amd64/kubectl
$ chmod +x ./kubectl
$ kubectl

建立 Kubernetes 容器叢集

1
$ kops create cluster --name=<叢集名稱>  --state=s3://<S3 儲存桶名稱>  --zones=us-east-1d  --master-size=<EC2 實體類型>  --node-size=<EC2 實體類型>  --node-count=2  --dns-zone=<網域名稱>

更新 Kubernetes 容器叢集

1
$ kops update cluster <叢集名稱> --state=s3://<S3 儲存桶名稱> --yes

驗證 Kubernetes 容器叢集

1
$ kops validate cluster <叢集名稱> --state=s3://<S3 儲存桶名稱>

取得 Kubernetes 容器叢集中的 Node 狀態

1
$ kubectl get nodes

部署 SAS Viya 服務至 Kubernetes 容器叢集

1
2
3
4
$ cd /sas-container-recipes
$ kubectl create -f viya-visuals/working/manifests/kubernetes/configmaps/
$ kubectl create -f viya-visuals/working/manifests/kubernetes/secrets/
$ kubectl create -f viya-visuals/working/manifests/kubernetes/deployments-mpp/

取得 Kubernetes 容器叢集中的 Pod 狀態

1
$ kubectl get pods

建立 Kubernetes 容器叢集專用的 ELB 負載平衡服務

1
$ vi sas-viya-visual.yml
1
2
3
4
5
6
7
8
9
10
11
12
13
apiVersion: v1
kind: Service
metadata:
name: sas-viya-visual
spec:
selector:
app: sas-viya-httpproxy
ports:
- name: http
port: 80
protocol: TCP
targetPort: 80
type: LoadBalancer
1
$ kubectl create -f sas-viya-visual.yml

取得 Kubernetes 容器叢集中的 Services 狀態

1
$ kubectl get svc

取得 sasboot 管理者帳號的重設密碼之網站連結

1
2
3
$ kubectl get pods
$ kubectl exec -it <sas-viya-coreservices 之 Pod 名稱> -- /bin/bash
$ grep sasboot `ls -tr /opt/sas/viya/config/var/log/saslogon/default/sas-saslogon_* | tail -n 1`

總結當我們建立 Docker Hub 倉庫之後,每次若要以 Kubernetes 容器叢集部署 SAS Viya 服務,不包括拉下 Docker 映像檔,則僅需要半小時就能夠完成部署,當然我們更能夠透過「kops」工具快速刪除 Kubernetes 容器叢集,以節省 AWS 雲端服務的測試成本,至於有關更多進階的設定,像是 LDAP 設定、SAS Studio 登入、SAS/ACCESS 存取、…,之後有空再進行心得分享。

刪除 Kubernetes 容器叢集

1
$ kops delete cluster --name=<叢集名稱> --state=s3://<S3 儲存桶名稱> --yes

相關資源

SAS Viya (51)

教學目標

初步了解在 SAS Viya 3.4 平台中更新授權碼的基本概念。

重點概念

首先 SAS Viya 提供授權檔主要由兩個檔案格式所組成,分別為為文字檔格式 (.txt) 和 JSON Web Tokon 檔格式 (.jwt),不同的 SAS Viya 產品將會採用不同授權的檔案格式,並且 SAS Cloud Analytic Services (CAS) 和 SAS Programming Run-time Environment (SPRE) 皆使用相同的授權,在安裝期間授權檔將會被套用至 CAS In-memory Compute Engine 和 SAS Programming Run-time Environment 中,請注意每台 CAS 伺服器皆需要套用授權檔,像是 CAS Controller、CAS Secondary Controller 和 CAS Worker。

接著當我們發現授權碼快要到期時,將要如何套用新的授權碼檔呢?建議透過 Ansible 工具套用新的授權碼檔至至 CAS Controller 、 CAS Secondary Controller 和 CAS Worker 和 SAS Programming Run-time Environment 中,相關步驟如下所示:

  1. 登入至 Ansible Controller 所在的機器,不一是 CAS Controller 伺服器,並且複製兩個授權檔至「sas_viya_playbook」資料夾中。
  2. 編輯「vars.yml」設定檔中的「LICENSE_FILENAME」和「LICENSE_COMPOSITE_FILENAME」對應授權檔案,「LICENSE_FILENAME」對應文字檔格式 (.txt) 和「LICENSE_COMPOSITE_FILENAME」對應 JSON Web Tokon 檔格式 (.jwt)。
  3. 以「Ansible」工具執行「apply-license.yml」腳本檔套用授權檔,請注意若有多台 CAS 伺服器,則建議使用「inventory」檔進行部署。

編輯「vars.yml」設定檔

1
2
3
4
5
6
7
# The name of the license file on the Ansible machine.
LICENSE_FILENAME: "SASViyaV0300_XXXXXX_Linux_x86-64.txt"

# The name of the composite license file on the Ansible machine.
# If both files are present, the playbook will use the
# composite license file.
LICENSE_COMPOSITE_FILENAME: "SASViyaV0300_XXXXXX_YYYYYYYY_Linux_x86-64.jwt"

執行「apply-license.yml」腳本檔

1
# ansible-playbook apply-license.yml

再來當授權碼更新完成之後,我們就能夠登入至 SAS Studio V 輸入以下指令確認是否成功更新授權碼至 CAS 伺服器,主要會顯示關於、系統和授權碼三個部份的資訊。

確認 CAS 伺服器中的授權碼資訊

1
2
CAS CASAUTO;
CAS CASAUTO LISTABOUT;

最後我們除了確認 CAS 伺服器中的授權碼資訊,建議也針對 SAS 伺服器進行確認,主要登入至 SAS Studio V 輸入以下指令確認是否成功更新授權碼至 SAS 伺服器,主要會顯示授權碼、SAS Viya 產品的資訊。

確認 SAS 伺服器中的授權碼資訊

1
PROC SETINIT;RUN;

相關資源

SAS 系統管理 (102)

教學目標

初步了解 SAS 9 平台中網頁應用程式伺服器的重點概念。

重點概念

首先 SAS 9 平台中的網頁應用程式伺服器皆是基於 Pivotal tc Server 開發,所謂 tc Server 主要是基於開放源始碼 Apache Tomcat ,所謂 Tomcat 主要是由 Apache 軟體基金會下 Jakarta 專案開發的 Servlet 容器,按照 Sun Microsystems 提供的技術規範,實現了對 Servlet 和 JavaServer Page(JSP)的支援,並且實作網站應用程式伺服器的一些功能。而 Tomcat 最外層的容器稱為 Server 代表整個伺服器,其中至少包括一個 Service,主要用於具體提供服務,而 Service 主要包括兩個部分,分別為 Connector 和 Container,所謂 Connector 主要是負責網路連線和請求回應等相關事件,所謂 Container 主要是用於封裝和管理 Servlet 以及處理相關請求。請注意一個 Tomcat 只能有一個 Server,一個 Server 可以包括多個 Service,一個 Service 可以包括多個 Connector,但是只能有一個 Container。

接著 Tomcat 中的 Server 主要是由 org.apache.catalina.startup.Catalina 類別服務進行管理,所謂 Catalina 服務就是整個 Tomcat 的管理類別。其中主要有三個方法分別為 load、start 和 stop,主要用於管理整個伺服器的生命週期,load 方法主要用於根據 server.xml 檔案建立伺服器,而 start 方法則是啟動伺服器,至於 stop 方法則是停止伺服器。若以 SAS 平台中 SASServer1_1 伺服器為例,則一開始就會啟動 Catatlina 服務。

啟動 Catatlina 服務

1
2
2018-12-20 13:33:58,597 INFO  (WrapperSimpleAppMain) [org.apache.catalina.startup.Catalina] Initialization processed in 557 ms
2018-12-20 13:33:59,347 INFO (WrapperSimpleAppMain) [org.apache.catalina.core.StandardService] Starting service Catalina

再來 Tomcat 中的 Container 主要是由 Engine、Host、Context 和 Wrapper 四個子容器所組成,所謂 Engine 主要是用於管理多個站點,但是一個 Service 僅會有一個 Engine,所謂 Host 主要代表一個站點,也能夠稱為虛擬主機,所謂 Context 主要代表一個應用程式皆會對應一個 web.xml 設定檔,所謂 Wrapper 主要代表一個 Servlet。其中 Host 和 Context 的差別在於 Context 代表一個應用,預設在 webapps 資料夾下的每個目錄皆是一個應用,其中 ROOT 目錄中存放著主應用,其它目錄存放著子應用。若以 SAS 平台中 SASServer1_1 伺服器為例,則會先啟動 Engine 容器,之後依序部署子應用設定描述檔 (XML 檔案),此外部署過程中會建立 SecureRandom 實體以利產生 Session ID,但在 Windows 平台主要預設會以 SHA1PRNG 演算法為主,所以不影響效能。

啟動 Engine 容器

1
2018-12-20 13:33:59,347 INFO  (WrapperSimpleAppMain) [org.apache.catalina.core.StandardEngine] Starting Servlet Engine: Pivotal tc Runtime 3.0.0.RELEASE/7.0.55.A.RELEASE

部署 XXX 子應用設定

1
2
2018-12-20 13:33:59,347 INFO  (localhost-startStop-4) [org.apache.catalina.startup.HostConfig] Deploying configuration descriptor D:\SAS\Config\Lev1\Web\WebAppServer\SASServer1_1\conf\Catalina\localhost\XXX.xml
2018-12-20 13:34:21,172 INFO (localhost-startStop-2) [org.apache.catalina.startup.HostConfig] Deployment of configuration descriptor D:\SAS\Config\Lev1\Web\WebAppServer\SASServer1_1\conf\Catalina\localhost\XXX.xml has finished in 21,825 ms

建立 SecureRandom 實體

1
[org.apache.catalina.util.SessionIdGenerator] Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [171] milliseconds.

最後當所有子應用皆部署完成之後,就會啟動 Tomcat 伺服器, 若以 SAS 平台中 SASServer1_1 伺服器為例,在實務上客戶端啟動時間通常需要 10 分鐘至 15 分鐘,主要花費的時間皆在於載入子應用設定為主,若子應用設定越多,則啟動時間越慢,至於是否能夠優化啟動時間,就目前測試若採用 m5.xlarge 等級的 AWS 雲端主機 (4 個 vCPU 、 16GB 記憶體和最多 3,500Mbps 的 EBS 頻寬),在不調整硬碟每秒輸入/輸出 (IOPS) 的情況下就能夠將啟動時間縮短為 3 分鐘至 5 分鐘。

啟動 Tomcat 伺服器

1
2
3
2018-12-20 13:36:20,560 INFO  (localhost-startStop-5) [org.apache.catalina.startup.HostConfig] Deploying web application directory D:\SAS\Config\Lev1\Web\WebAppServer\SASServer1_1\webapps\ROOT
2018-12-20 13:36:20,888 INFO (localhost-startStop-5) [org.apache.catalina.startup.HostConfig] Deployment of web application directory D:\SAS\Config\Lev1\Web\WebAppServer\SASServer1_1\webapps\ROOT has finished in 328 ms
2018-12-20 13:36:20,914 INFO (WrapperSimpleAppMain) [org.apache.catalina.startup.Catalina] Server startup in 142317 ms

總結 SAS 平台中的網站應用程式伺服器主要以 Tomcat 伺服器為基礎進行開發,因此深入了解 Tomcat 伺服器核心原理將有助於平台開發與維運,此外使用者主要會透過 Apache HTTP Server 網站伺服器連線至不同的網站應用程式伺服器,此時必須要注意網站伺服器設定檔中的「stickysession」參數值是否與網站應用程式伺服器設定檔「context.xml」中的「sessionCookieName」參數值一致,至於為何要一致細節之後再分享啦。

相關資源

SAS 系統管理 (101)

教學目標

初步了解 SAS 9 平台設定 SAS WORK 暫存檔案儲存空間的重點概念。

重點概念

首先 SAS 在工作階段執行期間將會需要暫存的磁碟空間,也就是所謂的 SAS WORK,預設 SAS 會儲存 SAS 暫存檔案至暫存的磁碟空間中,而暫存檔案主要則是當 SAS 階段結束之後將會直接被刪除,若沒有被正常刪除的檔案,則建議透過 SAS 官方所提供 Cleanwork 工具進行清理。

接著我們要如何修改暫存的磁碟空間呢?其實只要修改 sasv9.cfg 設定檔即可,我們僅需要加入以下參數。

修改 sasv9.cfg 設定檔

1
-work /disk1/directory

再來我們要如何設定多個暫存的磁碟空間呢?主要有兩種類型,分別為隨機 (Random) 和空間 (Space),隨機主要就是分散讀寫至不同的磁碟空間,空間主要就是選取最大的磁碟空間,但是設定則需要先建立 /sasinfo/workfiles 檔案,接著再修改 sasv9.cfg 設定檔即可

隨機 (Random)

新增 /sasinfo/workfiles 設定檔

1
2
3
4
/disk1/directory
/disk2/directory
/disk3/directory
method=random

修改 sasv9.cfg 設定檔

1
-work /sasinfo/workfiles

空間 (Space)

新增 /sasinfo/workfiles 設定檔

1
2
3
4
/disk1/directory
/disk2/directory
/disk3/directory
method=space

修改 sasv9.cfg 設定檔

1
-work /sasinfo/workfiles

最後我們可以先從 SAS Work 磁碟空間開始進行 SAS 平台的效能優化,當 SAS Work 磁碟空間讀寫效能越快,則 SAS 平台執行效能相對更佳。此外我們更能夠透過以下 SAS 程式查看其它與效能相關的參數設定,至於要如何更進階優化方式之後再分享啦。

查看效能相關設定選項

1
2
proc options group=performance; 
run;

相關資源