SAS Viya

SAS Viya (84)

教學目標

初步了解 SAS Viya 平台 CAS 資源管理設定政策的基本概念。

重點概念

首先 CAS 資源管理可用於限制 CAS 資源利用率,我們主要針對 CAS 伺服器定義政策限制 CAS 伺服器的 CPU 和磁碟快取暫存的資源,像是對於特定的使用者角色會有不同的資源分配,或者在企業中不同部門將會進行系統資源的成本比例分攤管理與控制,至於為何不採用多個 CAS 伺服器呢?與多個 CAS 伺服器的比較表,請參考下表。

技術 優點 缺點
CAS 資源管理 無需額外的機器,較少資料維護管理,以及無需額外授權。 分享 CAS 伺服器的資源。
多個 CAS 伺服器 無需分享 CAS 伺服器的資源。 需要額外的機器、較多資料維護管理,以及需要額外授權。

其中政策只能由 CAS 超級使用者進行建立和管理,並且應用於分散式 CAS 伺服器中的所有機器,以及透過「sas-admin」指令工具將政策定義儲存在 SAS 設定伺服器 (Consul) 中,然而當我們要開始使用 CAS 資源管理之前必須先安裝「cgroups」內核功能,也就是安裝「libcgroup 」和「libcgroup-tools 」的 Linux 套件,並且確認「cgroups」的檔案系統已經被掛載,請參考 以下步驟:

1
2
3
4
# sudo yum -y install libcgroup libcgroup-tools
# systemctl start cgconfig
# systemctl enable cgconfig
# ls /sys/fs/cgroup

接著我們需要編輯「/opt/sas/viya/config/etc/cas/default/casconfig_usermods.lua」設定檔在其中增加「env.CAS_ENABLE_CONSUL_RESOURCE_MANAGEMENT=true」設定值,並且重新啟動 CAS Controller 伺服器,請參考 以下步驟:

1
# systemctl restart sas-viya-cascontroller-default

再來我們需要透過「sas-admin」指令工具建立政策定義範本,請參考 以下步驟:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# cd /opt/sas/viya
# mkdir policy
# cd /opt/sas/viya/home/bin
# ./sas-admin cas generate-cas-samples --output-location /opt/sas/viya/policy
Generating sample templates for use in creating caslibs...

Generating sample files for use in creating formats...

Generating sample files for use in creating CAS resource management policies...

Generating the MD5 checksums...

All available samples have been generated and are located in "/opt/sas/viya/policy".
# cd /opt/sas/viya/policy
# ls
caslib-templates formats-examples md5.txt policies-examples
# cd policies-examples
# ls
cas-shared-default-priority-2.json globalCaslibs.json priorityAssignments.json

此時我們將會發現產生了三個政策定義範本的檔案,其格式為 JSON,分別為:

  1. globalCaslibs.json
  2. cas-shared-default-priority-2.json
  3. priorityAssignments.json

其中所謂 globalCaslibs.json 為全域 CASLIBS 政策其主要用於在全域 CASLIB 上暫存空間的儲存配額,並且僅有一個全域 CASLIBS 政策定義檔。所謂 cas-shared-default-priority-2.json 為優先等級政策其主要用於在個人 CASLIB 上暫存空間的儲存配額和 CPU 核心數使用限制,並且最多五個優先等級政策定義檔,優先級從 1 (最高) 至 5 (最低) 進行編號。所謂 priorityAssignments.json 為強制特定用戶的優先等級,並且僅有一個強制特定用戶的優先等級定義檔。

編輯「cas-shared-default-priority-2.json」政策定義檔

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# vi cas-shared-default-priority-2.json 
{
"_COMMENT_1_": "These are sample values and are not intended for actual use.",
"_COMMENT_2_": "The following limits have been set.",
"_COMMENT_3_": "55 CPU Shares",
"_COMMENT_4_": "9.31GB quota for all casuser caslibs",
"_COMMENT_5_": "27.94GB quota for all HDFS casuser caslibs",
"_COMMENT_6_": "4.66GB quota for all session-scoped tables",
"attributes": {
"cpu": "55",
"globalCasuser": "10000000000",
"globalCasuserHdfs": "30000000000",
"sessionTables": "5000000000"
},
"name": "cas-shared-default-priority-2",
"type": "priorityLevels"
}

編輯「globalCaslibs.json」政策定義檔

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# vi globalCaslibs.json
{
"_COMMENT_1_": "These are sample values and are not intended for actual use.",
"_COMMENT_2_": "The following limits have been set.",
"_COMMENT_3_": "CustomerCreatedCaslib1 has a quota of 37.25GB.",
"_COMMENT_4_": "Public has a quota of 4.66GB.",
"_COMMENT_5_": "ReferenceData has a quota of 13.97GB.",
"_COMMENT_6_": "SystemData has a quota of 18.63GB.",
"attributes": {
"CustomerCreatedCaslib1": "40000000000",
"Public": "5000000000",
"ReferenceData": "15000000000",
"SystemData": "20000000000"
},
"name": "globalCaslibs",
"type": "globalCaslibs"
}

編輯「priorityAssignments.json」政策定義檔

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# vi priorityAssignments.json
{
"_COMMENT_1_": "These are sample values and are not intended for actual use.",
"_COMMENT_2_": "The following assignments have been specified.",
"_COMMENT_3_": "userID1 is in priority level 5.",
"_COMMENT_4_": "userID2 is in priority level 2.",
"_COMMENT_5_": "userID3 is in priority level 3.",
"_COMMENT_6_": "userID4 is in priority level 4.",
"attributes": {
"userID1": "5",
"userID2": "2",
"userID3": "3",
"userID4": "4"
},
"name": "priorityAssignments",
"type": "priorityAssignments"
}

當我們編輯完成政策定義檔之後,請透過「sas-admin」指令工具將政策定義儲存在 SAS 設定伺服器 (Consul) 中,請參考 以下步驟:

1
2
3
4
# cd /opt/sas/viya/home/bin
# ./sas-admin cas servers policies define global-caslibs --server cas-shared-default --source-file cas-shared-default-globalCaslibs.json
# ./sas-admin cas servers policies define priority-levels --server cas-shared-default --priority 1 --source-file cas-shared-default-priority-2.json
# ./sas-admin cas servers policies define priority-assignments --server cas-shared-default --source-file cas-shared-default-priorityAssignments.json

最後我們需要在 SAS Environment Manager 中建立名為「cas-shared-default-priority-2」的客製群組,並且將多個 CAS 使用者分配給該群組,請注意客製群組名稱必須與優先等級政策的名稱對應。當設定完成之後,當使用者建立 CAS 連線會話時,其將會搜尋該使用者的群組,如果能夠找到對應的 CAS 政策,則 CAS 伺服器會在相應的 cgroup 中強制執行任何 CPU 限制和任何暫存儲存空間的配額限制,同時如果該使用者具有多個優先等級政策對應群組的成員,則 CAS 伺服器會將其分配給最低優先等級政策,其優先等級主要是從 1 (最高) 到 5 (最低) 編號。此外若超過限制,則會在操作時產生「XXX quota exceeded.」或「TKCASTAB_QUOTA_EXCEEDED」的錯誤訊息。

相關資源

SAS Viya (83)

教學目標

初步了解 SAS Viya 平台關鍵服務和微服務的基本概念。

重點概念

首先許多客戶會問是否需要監控所有 SAS Viya 平台的服務和微服務呢? 若不需要,則有哪些關鍵的服務和微服務,我們主要可以分為三大類別,分別為:

  1. 關鍵基礎架構服務
  2. 關鍵功能微服務
  3. 關鍵網站應用程式

接著所謂關鍵基礎架構服務主要在啟動其它 SAS Viya 關鍵功能微服務之前,就必須先啟動和執行的服務,並且按照以下順序從上到下的依賴關係進行啟動,分別為:

  1. consul
  2. vault
  3. rabbitmq
  4. postgres
  5. httpd
  6. cas-shared-default
  7. cas-shared-default-http
  8. cachelocator
  9. cacheserver

請注意若是其中一項服務停止將會使得 SAS Viya 平台無法按預期正常使用,並且重新啟動其中一些服務可能需要重新啟動 SAS Viya 平台,其中 cas-shared-default 和 cas-shared-default-http 需要特別注意,因為與資料可用性非常相關。

再來所謂關鍵功能微服務主要在使用 SAS Viya 關鍵網站應用程式之前,就必須先啟動和執行的服務,但是沒有強制的相依順序,但是不同功能微服務將會有不同的功能,像是 SASLogon 就是用於登入的微服務,所以對於採用單一登入機制的 SAS Viya 平台非常重要,所以我們必須先確認是否正常啟動,而在 SAS Viya 平台中有許多關鍵功能微服務,分別為:

  1. SASLogon
  2. identities
  3. launcher
  4. compute
  5. object-spawner
  6. ops-agent
  7. ops-agentsrv
  8. watch-log
  9. licenses
  10. backup-agent

最後所謂關鍵網站應用程式主要皆是視覺化使用者操作界面,所以若這些服務或微服務未正常啟動,則使用者將會無法按預期使用 SAS Viya 平台,此時可能會有 503 或 404 等錯誤訊息,而當我們直接透過 curl 指定連結至任關鍵網站應用程式對應的網址,若是回應 401 未驗證的錯誤訊息,則代表該網站應用程式已經啟動成功,而在 SAS Viya 平台中有許多關鍵網站應用程式,分別為:

  1. SASEnvironmentManager
  2. SASBackupManager
  3. SASDrive
  4. SASStudio
  5. SASStudioV
  6. SASDataExplorer
  7. SASDataStudio
  8. SASGraphBuilder
  9. SASJobExecution
  10. SASLineage
  11. SASQKBManager
  12. SASReportViewer
  13. SASThemeDesigner
  14. SASVisualAnalytics

因此當我們遇到 SAS Viya 平台發生異常狀況時,請先判斷屬於哪個類別的 SAS Viya 服務或微服務,再採用對應的故障排除任務,像是若發現是特定網站應用程式發生異常,則僅需重新啟動該網站應用程式,但若發現是關鍵基礎架構服務發生異常,則可能需要重新啟動 SAS Viya 平台,請注意若僅是 CAS 伺服器相關服務發生異常,則僅需重新啟動 CAS 伺服器相關服務,也就是 cas-shared-default 和 cas-shared-default-http 通常啟動在幾秒之內完成,但是當 CAS 伺服器重新啟動之後,則 CAS 伺服器記憶體中的資料表就必須重新載入。

相關資源

SAS Viya (82)

教學目標

初步了解 SAS Viya 平台 CAS 資源管理的基本概念。

重點概念

首先在 SAS Viya 中將能夠透過 CAS 資源管理的功能重新分配 CAS 連線資料處理使用的 CPU 資源,現在主要能夠使用優先等級策略為已經加載的資料表定義磁碟配額,並且將 CPU 容量分配給不同的使用者群組,最多五個群組,至於此功能主要利用 Linux 作業系統中 cgroups 的內核功能,因此若我們想要使用 CAS 資源管理的功能,則必須在 CAS 機器上安裝 cgroups 內核功能。

接著我們主要使用 cas.MEMORYSIZE 伺服器設定選項將 CAS 機器節點上的記憶體使用量限制為特定數量的記憶體,以及 cas.CPUSHARES 伺服器設定選項將 CAS 機器節點上的 CPU 使用量限制為總 CPU 容量的一部分。此外我們更會透過使用者群組關聯兩種類型的政策,分別為:

  1. 全域 CASLIBS 政策 (globalCaslibs) :每個 CAS 伺服器僅有一個政策主要用於全域 CASLIBS 上儲存暫存空間的配額。
  2. 優先等級政策 (CAS-server-name-priority-n):每個 CAS 伺服器有一備五個政策主要用於個人 CASLIB 上儲存暫存空間的配額,並且將能夠對應至使用者群組的 CAS 連線會話的 CPU 消耗限制。

其中政策主要是當 SAS Viya 平台啟動時,CAS 伺服器將會讀取 Consul 中定義的政策,並且動態建立 cgroup 設定以利限制使用的資源,請注意資源管理政策僅在 SAS Viya 完全部署中進行工作,因為需要 SAS 設定伺服器來儲存相關設定值,而當停止 CAS 伺服器時將會刪除政策中相關的 cgroup 設定。

再來管理員將能夠根據不同的使用者群組以優先級政策分配使用者配額,請注意 SAS 管理員必須通過 SAS Viya 命令行界面 (CLI) 在 Consul 儲存中定義政策,並且在 Environment Manager 中建立對應的自定義群組,再將最終使用者與資源管理群組進行相關聯,像是我們能夠建立三個優先級政策,其中一個用於報表使用者、一個用於資料處理使用者,一個用於數據科學家,其 CPU 重新分配為 20%、30% 和 50%,並且定義不同的配額以利限制用於每個群組的全域 CASLIBS,連線 SESSION 或載入 HDFS 資料表,以利限制報表使用者使用空間量,以及避免資料科學家瘋狂執行單個,但是非常繁重的機器學習和高級分析操作,其將會佔用 CAS 叢集中的所有 CPU 資源。

最後若我們需要使用 CAS 資源管理政策,則必須在「casconfig_usermods.lua file」設定檔中設定環境變數「 env.CAS_ENABLE_CONSUL_RESOURCE_MANAGEMENT」設為「 ‘true’」,請注意設定值大小寫有差,並且我們必須具有 CAS 超級使用者權限才能夠建立和管理資源管理策略。此外政策限制適用於分散式 CAS 伺服器的每台機器,政策主要從 JSON 範本中建立,以及透過 SAS Viya 命令界面進行管理,預設情況為關閉,所以需要手動啟動,而 CAS 伺服器主要會將政策儲存為 SAS 設定伺服器 (Consul) 中的鍵值配對 (Key Value Pairs),至於 CAS 資源管理政策如何運作,請參考 SAS Viya 官方文件

相關資源

SAS Viya (81)

教學目標

初步了解在 AWS 雲端平台上部署 SAS Viya 平台的基本概念。

重點概念

首先規劃不同 SAS Viya 元件的硬體配置將會考量不同的特性,規劃微服務和網站伺服器主要會根據不同的微服務類型和同時在線使用者連線數 (Session) 決定記憶體大小和低網路延遲,規劃運算伺服器主要需要高 CPU,規劃 CAS 伺服器主要需要高 CPU、高記憶體、高儲存輸出、高網路頻寬和低網路延遲,規劃架構伺服器主要需要低網路延遲,規劃 Elasticsearch 伺服器主要需要高 CPU、高記憶體、高儲存每秒的讀寫次數、高網路頻寬和低網路延遲,因此我們能夠根據上述原則規劃不同 SAS Viya 元件的硬體配置,並且當規劃在 AWS 雲端平台部署 SAS Viya 平台時,則建議採用記憶體優化執行個體 (Memory Optimized Instances),或者針對微服務則建議採用一般用途執行個體 (General Purpose Instances),通常不建議採用運算優化執行個體 (Compute Optimized Instances),因為 SAS Viya 的授權是以核心數計價,並且運算伺服器和 CAS 伺服器同時需要高 CPU 和高記憶體的情況將會以記憶體為主,以及不建議採用儲存優化執行個體 (Storage Optimized Instances),因為會根據 SAS Viya 元件的配置選擇適當的 AWS EC2 Instance Store 執行個體資料儲存、AWS EBS 持久性資料區塊級儲存磁碟區和 AWS EFS 共享檔案儲存服務相關配置,至於不同 SAS Viya 元件的硬體配置之詳細資訊,請參考下表。

元件 CPU 記憶體 儲存輸出 儲存每秒的讀寫次數 網路延遲 網路頻寬
Microservices and Web Application Moderate High Moderate Moderate Low Low
Compute Server High Moderate Moderate Moderate Low Moderate
Infrastructure Server Moderate Moderate Moderate Moderate Low Moderate
CAS Server High High High Moderate Low High
Elasticsearch Server High High Moderate High Low High

(註:高儲存輸出主要為每個核心數至少 100MBps。)

接著規劃 SAS Viya 平台需考慮硬體配置之外,高效能的檔案系統的配置也是非常重要,我們主要考量運算伺服器和 CAS 伺服器中檔案系統的配置,像是運算伺服器因為會執行 SAS Studio 和工作區所以需要考量 SASWORK 暫存目錄、SASUTIL 暫存目錄、SAS DATA 儲存目錄的檔案系統配置,而 CAS 伺服器會分為 CAS Controller 和 CAS Worker,其中 CAS Controller 主要當採用序列載入 (Serial Loading) 時,則會考量 CAS_CONTROLLER_TEMP 快取目錄和 SAS 資料集儲存的檔案系統,以及考慮 CAS DATA 儲存目錄的檔案系統 (/opt/sas/viya/config/data/cas/default),因為視覺化分析、視覺化文字分析、視覺化預測分析、… 等皆會大量存取 CAS 內容設定檔,至於 CAS Worker 主要當採用平行載入 (Parallel Loading) 時,則會考量 CAS_DISK_CACHE 快取目錄的檔案系統。此時若我們要在 AWS 雲端平台上部署 SAS Viya,則要選擇哪類型的儲存空間的詳細資訊,請參考下表。

檔案系統 儲存服務 儲存類型 暫時儲存 持久儲存
SASWORK Instance Store NVMe SSD Y N
SASUTIL Instance Store NVMe SSD Y N
SAS DATA EBS Throughput Optimized HDD N Y
CAS DATA EBS Provisioned IOPS SSD N Y
CAS_CONTROLLER_TEMP Instance Store NVMe SSD Y N
CAS_DISK_CACHE Instance Store NVMe SSD Y N

再來在 SAS Viya 平台中主要有五種應用情境需要共享的檔案系統,分別為:

  1. Multiple Compute Server
  2. High available CAS Servers
  3. Parallel loading using DNFS from CAS Workers
  4. High available SAS infrastructure Data Server
  5. Backup Service

至於應用情境所對應儲存的詳細資訊,請參考下表。

應用情境 儲存目錄 儲存需求 儲存服務 儲存模式
Multiple Compute Server HOME DATA, SAS DATA Moderate Throughtput EFS General Purpose, Bursting Throughput, Provisioned Throughtput
High available CAS Servers CAS DATA High Throughtput EFS General Purpose, Bursting Throughput, Provisioned Throughtput
Parallel loading using DNFS from CAS Workers SAS DATA High Throughtput EFS General Purpose
High available SAS infrastructure Data Server SANMOUNT Moderate to high IOPS EFS General Purpose
Backup Service BACKUP DATA Low Throughtput and IOPS EFS General Purpose

(註:若在 SAS Viya 平台採用 DNFS 分散式儲存,則針對 SAS DATA 和 CAS DATA 建議使用 Bursting Throughput 儲存模式。)

最後 SAS Viya 平台中備份服務主要會針對四種內容進行備份,分別為:

  1. SAS Configuration Server (Consul)
  2. SAS Message Broker Server (RabbitMQ)
  3. SAS Infrastructure Data Server (PostgreSQL)
  4. Cloud Analytic Services Permstore (CAS)

其中 SAS Viya 備份服務需要在所有執行個體上掛載共享檔案系統,並且設定為 Shared Vault 備份路徑,至於作業系統、部署檔案、使用者目錄和資料目錄,則需要透過第三方工具進行備份,所以當在 AWS 雲端平台部署 SAS Viya 平台時,則建議透過 Amazon Machine Image 針對每個執行個體在成功部署之後進行機器映像檔備份,並且手動或排程方式建立使用者目錄和資料目錄對應 AWS EBS 持久性資料區塊級儲存磁碟區的快照和執行 SAS Viya 備份服務儲存至 AWS EFS 共享檔案儲存服務的空間中,至於還原方式主要先還原機器映像檔備份,並且確認與部署 SAS Viya 完成時相同的 IP 位置,以及透過 AWS EBS 持久性資料區塊級儲存磁碟區的儲存空間的快照還原使用者目錄和資料目錄,最後執行 SAS Viya 備份服務從 AWS EFS 共享檔案儲存服務的空間中還原上述四種內容。

相關資源

SAS Viya (80)

教學目標

初步了解在 AWS 雲端平台上部署 SAS Viya 平台的基本概念。

重點概念

首先雲端運算主要有公有雲、私有雲和混合雲,但是大多數的企業客戶主要會使用多種雲端服務進行數位轉型,雲端服務的類型主要有基礎架構即服務 (IaaS)、平台即服務 (PaaS)、軟體即服務 (SaaS) 和商業流程即服務 (Business Process as a Service),其中基礎架構即服務的雲端服務目前還是以 Amazon Web Services (AWS) 雲端服務為企業領導者。而 SAS 目前則有提供在 Amazon Web Services (AWS) 雲端上部署 SAS 平台,在 AWS 驗證的環境中提供 SAS 分析、資料視覺化以及機器學習功能,至於部署公有雲的方法主要有兩種,分別為:

  1. 傳統部署方法:客戶提供虛擬機器和在安裝設定 SAS Viya 平台執行前置安裝設定,以及透過 Ansible 進行手動部署,時間會以天和週為單位,但是能夠部署任何架構。
  2. 快速開始方法:客戶透過雲端入口網站使用 SAS Viya Quick Start 範本自動部署 SAS Viya 平台,時間會以小時為單至,但是僅能夠部署固定架構。

簡單來說,假設客戶希望使用 SAS Viya 分析功能擴展模型開發的過程,並且客戶沒有基礎設施,也沒有安裝 SAS Viya 的經驗,此時就不建議採用傳統部署方法,而是建議採用快速開始方法,將能夠大大節省提取硬體採購和配置、部署規劃和與 IT 的協調以及軟體安裝和配置所需的工作量和時間。

接著 AWS 雲端服務目前主有二十一個地理區域,每個地理區域皆會有多個可用區域,所有可用區域之間提供高輸送量、低延遲與完全冗餘的專用光纖連線,像是 AWS 上的 SAS Viya 快速部署範本主要部署在一個可用區域,而當客戶需要部署 SAS Viya 災難復原的規劃時,我們則需要將 SAS Viya 部署至二個不同的可用區域,此時部署 SAS Viya 則建議會將 CAS Controller 、 CAS Worker 和 Viya Services 分別部署至不同的虛擬機器中,而為了同時滿足恢復時間目標 (Recovery Time Objective,RTO) 和雲端服務成本目標,建議停用 CAS Controller 和 CAS Worker 所有虛擬機器,因為 Viya Services 啟動需要二十分鐘,然而 CAS Controller 和 CAS Worker 則不需要三十秒,因此僅啟動 CAS Controller 和 CAS Worker 所有虛擬機器將能夠滿足恢復時間目標和雲端服務成本目標 。此外 AWS 雲端服務更有提供節點能夠針對全世界的主要城市透過 AWS CloudFront 和 AWS Rroute 53 透過快取資料發佈內容至終端使用者以利降低網路延遲。除此之外 AWS 雲端服務更有提供虛擬私有雲 (VPC) ,並且能夠區分公有子網路和私有子網路,像是 AWS 上的 SAS Viya 快速部署範本中的公有子網路主要有 Ansible Controller、NAT Gateway 和 Elastic Load Balancing (ELB),私有子網路主要有 CAS Controller 和 Viya Services。至於公有子網路和私有子網路主要差別在於公有子網路預設會連線至虛擬私有雲中 Internet Gateway 連線至網際網路,而私有子網路則需要連線至 NAT Gateway 和 Elastic Load Balancing (ELB) 連線至網際網路,像是 AWS 上的 SAS Viya 快速部署範本中的 CAS Controller 透過 NAT Gateway 連線至網際網路下載相關套件,Viya Service 透過 Elastic Load Balancing (ELB) 除了連線至網際網路下載相關套件之外,更提供對外連線至 SAS Viya 的網站服務,所謂 Elastic Load Balancing (ELB) 主要是用於網路流量的負載平衡,可分為應用程式負載平衡器和網路負載平衡器,至於部署 SAS Viya 主要以應用程式負載平衡器達到高可用性架構為主,而在實務應用中我們通常會將網站伺服器部署至公有子網路,而會將應用程式伺服器和資料庫部署至私有子網路。

再來 AWS 雲端服務目前有提供 AWS Network Access Control List (NACL) 控管子網路的存取控制,以及 AWS Security Group 控管虛擬機器實體的存取控制,請注意 AWS Security Group 僅能夠設定允許規則,不像 AWS Network Access Control List (NACL) 能夠設定允許規則和拒絕規則,以及 AWS Security Group 主要為 Stateful,而 AWS Security Group 主要為 Stateless,像是 AWS 上的 SAS Viya 快速部署範本中主要會針對公有子網路和私有子網路皆有對應不同的 AWS Network Access Control List (NACL) 存取控制,以及 Ansible Controller、 CAS Controller 和 Viya Services 虛擬機器實體皆有對應不同的 AWS Security Group 存取控制。此外在 AWS 上的 SAS Viya 快速部署範本中將會透過 AWS CloudWatch 用於部署和應用程式日誌,以利提供資料和可行的洞見以監控應用程式、了解並回應整個系統的效能變化、優化資源使用情況,以及透過整合的檢視來查看運作狀態,以及在 AWS 上的 SAS Viya 快速部署範本中將會透過 Amazon Simple Notification Service (Amazon SNS) 發送電子郵件部署開始和結束時的通知,因此當我們透過 AWS 上的 SAS Viya 快速部署範本產生 SAS Viya 環境之後,將能夠提供客戶有效進行安全控管和維運管理。

最後 AWS 雲端服務目前有提供 AWS Elastic Compute Cloud (EC2)、AWS Elastic Block Storage (EBS) 和 AWS Elastic File System (EFS) 雲端服務主要用於部署解決方案,像是 AWS 上的 SAS Viya 快速部署範本中主要透過 AWS Elastic Compute Cloud (EC2) 建立 Ansible Controller、 CAS Controller 和 Viya Services 虛擬機器實體,並且每個虛擬機器實體皆會掛載 AWS Elastic Block Storage (EBS) 儲存空間部署 SAS Viya 環境安裝檔和設定檔,以及掛載 AWS Elastic File System (EFS) 儲存空間部署環境共享設定檔,像是 SAS Viya 環境中的 CAS Controller 內容設定檔和 Shared Vault 備份設定檔。此外 AWS CloudFormation 主要用於提供一種可讓開發人員和系統管理員建立相關 AWS 資源集合的簡單方式,並透過按順序且可預測的方式進行佈建,其主要是以 JSON 和 YAML 資料格式進行設定,因此當我們採用 AWS 上的 SAS Viya 快速部署範本主要會透過 AWS CloudFormation 產生 SAS Viya 環境所需要的 AWS Elastic Compute Cloud (EC2) 和 AWS Elastic Block Storage (EBS) 雲端服務,請注意因為 AWS 上的 SAS Viya 快速部署範本主要為對稱多處理 (Symmetric Multi Processing,SMP),而非大量分散式處理 (Massively Parallel Processing,MPP),所以不需要採用 AWS Elastic File System (EFS) 儲存空間部署環境共享設定檔。

相關資源