雲端服務 Cloud Native (1)

教學目標

初步了解雲原生架構的基本概念。

重點概念

首先雲原生的概念最早是在 2015 年由 Pivotal 公司的 Matt Stine 撰寫了一本叫做遷移至雲原生應用架構的文件,我們能夠從官方網站免費下載 PDF 檔,其中探討了雲原生應用架構的主要特性,分別為:

  1. 十二個因素的應用程式 (Twelve-Factor Applications):雲原生應用程式架構的集合,其主要專注於透過宣告性設定來提高速度、安全性和規模橫向擴展,並且提供無狀態和無共享的程序,以及部署環境需要整體鬆散耦合。
  2. 微服務 (Microservices):微服務代表了整體業務的分解,並且將系統轉換為可以獨立部署的服務,並且最小的原子服務單元就是提供商業價值。
  3. 自主式服務的敏捷基礎設施 (Self-Service Agile Infrastructure):開發雲原生應用程式架構的團隊通常也會負責部署和持續運營,所以雲原生架構必須提供團隊自助式的服務平台,也就是快速、重複和一致的提供前端應用環境和後端服務平台。
  4. 基于 API 的協同合作 (API-Based Collaboration):在雲原生應用程式中服務之間的唯一互動模式主要是透過已經發佈和版本化的 API,這些 API 通常是具有 JSON 序列化的 HTTP REST 格式,但是也能夠使用其它協議和序列化格式,以利要團隊能夠部署新功能,以及自主式服務的敏捷基礎設施主要透過 API 請求互動進行提供、縮放和維護應用程式基礎設施的相關操作。
  5. 反脆弱 (Antifragile):所謂反脆弱的概念主要是受到壓力時變得更高品質的系統,像是將隨機讓正式環境產生故障,以利識別和消除架構中的缺陷,並且透過明確的查找出應用程式架構中的弱點,並且強制進行修復,此時架構自然會隨著時間的推移更大程度提供更高品質的系統。

接著雲原生應用程式架構的集合主要有十二個因素,分別為:

  1. 程式碼庫 (Codebase):每個部署的應用程式皆在版本系統中有一個獨立的程式碼庫,並且能夠在不同的環境部署多個實體。
  2. 相依 (Dependencies):每個部署的應用程式皆需要使用適當的工具針對相依關係進行顯式的宣告,而不會在在部署環境中隱式的實現相依關係。
  3. 設定 (Config):設定或其隨著發佈環境而變更的部份應該作為作業系統層級的環境變數進行注入。
  4. 後端服務 (Backing services):主要需要後端服務,並且部署在所有環境中皆相同執行。
  5. 建置、發佈和執行 (Build, release, run):主要需要建立一個能夠部署應用程式元件,並且綁定設定,以及根據元件和設定的組合來啟動一個或多個程序,請注意部署和設定這兩個階段是嚴格分離。
  6. 處理程序 (Processes):每個部署的應用程式執行一個或多個無狀態程序,並且它們之間不需要共享任何東西,至於任何需要的狀態皆會儲存於後端服務。
  7. 連接埠綁定 (Port binding):每個部署的應用程式皆是獨立的,並且透過連接埠綁定導出所有服務。
  8. 平行 (Concurrency):主要透過水平擴展應用程式處理程序來實現平行處理。
  9. 可任意處理 (Disposability):主要透過快速啟動和優雅的終止處理程序,實現最大程度的強建性,以利允許快速彈性縮放、部署更改和從崩潰中恢復。
  10. 開發和正式環境平台 (Dev/prod parity):主要透過保持開發、測試和正式環境盡可能相同的環境來實現持續交付和部署。
  11. 日誌記錄 (Logs):主要將日誌視為事件串流,並且允許執行環境透過集中式服務進行收集、聚合、索引和分析事件。
  12. 管理程序 (Admin processes):主要針對行政或管理類型的任務皆應該與應用程式長期執行的相同環境中一次性完成。

上述十二個因素非常適合快速部署應用程式,因為其不需要針對將要部署的環境進行任何設定,而是採用簡單而一致的機制,以利實現自動化和快速設定新環境的部署應用。

再來從高層次來看,雲原生架構意味著適應許多新的可能性,但與傳統的本地基礎架構相比,雲原生所提供的架構限制條件非常不同,雲原生主要提供非常不同的方式來滿足非功能性需求,如果架構師未能使他們的方法適應這些不同的限制條件,則其設計的系統通常是脆弱、昂貴,並且難以維護,但是架構良好的雲原生架構下的系統理應能夠很大程度的自我修復,具有成本效益,並且可以透過持續整合和持續交付,以利更容易更新和維護。此時雲原生架構有五大原則,這些原則將能夠有助於確保您的設計充分利用雲原生架構,同時避免將舊的方法帶入新平台的陷阱,分別為:

  1. 設計自動化 (Design for automation):自動化一直是軟體系統的最佳實務,自動化流程將能夠比手動更快速的進行修復,擴展和部署系統。
  2. 有效管理狀態 (Be smart with state):管理使用者資料或系統狀態是建構分散式雲原生架構最困難的部份,因此我們應該將針對狀態儲存進行設定,以及如何設計無狀態的元件服務。
  3. 支援託管服務 (Favor managed services):大多數的雲端提供商皆提供豐同的託管服務,以利我們免於管理後端平台或基礎架構的麻煩,因此託管服務通常能夠盡可能的節省組織時間和營運成本。
  4. 深度防禦方法 (Practice defense in depth):雲原生架構需要處理外部攻擊,因此他們透過在每個元件之間應用身份驗證,並且透過深度防禦方法最小化內部和外部元件之間的信任,除了身份驗證之外,更包括速率限制和腳本注入等內容,設計中的每個元件皆應該個保護本身免受其它元件的影響,這不僅使架構具有很強的彈性,並且使得雲端環境中部署服務的結果更加容易
  5. 不斷調整架構 (Always be architecting):雲原生架構的核心特徵之一是它始終在不斷發展,作為一個雲原生的架構師,隨著組織需求的變化,IT 系統的變化和雲端提供商本身的功能發生變化,我們應該始終尋求改進和簡化系統架構,雖然這無疑需要不斷的投資,若是 IT 系統無法迅速使組織陷入停滯,將無法應對新的威脅和機遇。

最後建構雲原生的架構主要測重於如何針對雲原生獨特功能優化系統架構,傳統架構傾向於針對固定的高成本基礎架構進行優化,這需要大量的手動修改,因此傳統架構主要側重於相對較小固定數量的元件彈性和效能。然而在雲原生架構中固定的基礎設施沒有多大意義,因為雲端環境是根據使用情況進行收費,這樣可以減少佔用空間時節省資金,而且自動化也更容易,因此自動放大和縮小要容易得多,所以雲原生架構主要側重於透過水平擴展,分散式處理和自動更換故障元件來實現彈性和擴展,同時我們遵循雲原生的架構原則將能夠更有效的改進和調整系統架構,以利適應下一個環境轉變。

相關資源

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 共享檔案儲存服務的空間中還原上述四種內容。

相關資源