在本系列文章中,Dominique Vernier 專家將詳細解釋如何創建和增強模式類型。 雖然作者使用的是來自 HTTP://www.aliyun.com/zixun/aggregation/13696.html">SmartCloud Application Services 的 IBM SmartCloud Application Workload Services,但是測試結果同樣適用于 SmartCloud Enterprise 和 IBM PureSystems 系列。
作為一名好奇的 IT 架構師,在閱讀了 developerWorks 文章 創建和定制虛擬應用程式模式 之後,我有一個問題:「建立模式類型有多困難」? 因此,我準備為一台單獨的伺服器構建一個模式類型,這個專案雖然比較簡單,但可以演示模式類型的基礎概念。
本文為這一過程提供了指南,使用了 我的博客 中一篇更全面的系列文章中的步驟。 每個小節都是完整說明的一個要目。 為了深入挖掘相關細節,您需要訪問連結,閱讀完整討論的 PDF 版本,或者閱讀我的博客中的文章。 PDF 是實際博客文章的副本,會定期更新;而實際博客文章的連結展示的可能是最新的資訊,您可以在本文中找到新的博客文章。
另請注意:和大多數系列文章一樣,每一段的內容都基於前面各段的內容,我研究了應用程式模型和物理模型的變化,以及如何通過測試來確保您的更改可以生效。
下載完整的PDF操作文檔:探索IBM SmartCloud Application Services
定義、概念、場景和設置
第一部分首先將描述模式類型 和模式 的區別:模式類型提供了構建模式所需的所有元件、連結、可伸縮性規則等。 建立模式類型要做的工作要比根據模式類型建立模式多。
然後,我們會簡要介紹以下場景:
模式類型只包含一個伺服器。 該伺服器有一個參數。 部署過程將在開始安裝時記錄一條消息。 部署過程將在部署期間的另一個時間點記錄一條消息。
我們還介紹了三個重要的概念:
一個模式類型通常由一個外掛程式組成,該外掛程式包含模式類型的定義以及一個或多個外掛程式,它們包含模式類型提供的功能,而外掛程式的數量則由架構決定。 您可以將一個外掛程式分解為兩個主要部分: 應用程式模型:定義設計虛擬應用程式模式所需的各種元件和連結。 物理模型:定義必須在目標雲上啟動的各種虛擬機器和腳本。 有兩種機制可以將應用程式模型映射到物理模型:一個基於 JAVA™ 的代碼機制和一個基於範本的機制(首選機制和推薦使用的機制)。
最後,我們介紹了本練習涉及的設置步驟:
創建一個工作空間。 導入模式類型和外掛程式。 修改模式類型的名稱。 編輯模式類型 JSON 描述。 為外掛程式創建一個新的 JAVA 專案。 創建一個外掛程式目錄。 將 META-INF 檔、build.plugin.xml 和 build.properties 複製到外掛程式目錄中。 更新外掛程式的 config.json 檔。
我還將討論並提供以下內容的代碼:
應用程式模型:在 plugin/appmodel/metadata.json 中定義。 您將瞭解如何設計和測試它。 物理模型:包含一個 VM 範本檔,定義了應當部署的虛擬元素和應用程式模型的角色。
最後我們還進行了測試,為順利進入第 2 部分做準備。
創建 Slave-Master 模式類型
下一個任務是創建一個 Master-Slave 模式類型;它有別于第 1 部分的練習,因為 Master 伺服器和 Slave 伺服器之間有一個連結,該連結從 Slave 伺服器檢索一些資訊(如 IP 位址)來配置 Master 伺服器。
第 2 部分的步驟包括:
檢查應用程式模型,查看我對它做的更改,這些更改是在應用程式模型的 JSON 檔中完成的(第 1 部分)。 我們還增加了一個連結類型元素,用它指定源和目標。 檢查物理模型的變化,瞭解如何更新 OSGI 目錄,並根據與 Slave 相關的 Master 重新構建各個部分。 瞭解如何進行測試以及會產生怎樣的結果。
向模式類型添加靜態可伸縮性
第 3 部分展示如何向 Master-Slave 模式類型添加靜態可伸縮性。 靜態可伸縮性的意思就是在模式設計期間定義實例的數量。
首先,向 Slave 元件附加一個策略元件,然後為該策略定義屬性,最後更改 Slave VM 範本,以便導入從應用程式模型收集的資訊。 (該功能十分重要,因為它還適用于 IBM Workload Deployer 和 IBM PureSystems 專家集成系統)。
向模式類型添加一個監控收集器
當然,為了實現動態可伸縮性(可伸縮性將對監控特性作出反應),您必須能夠從伺服器收集資訊。 這一部分的目標是能夠監視某個伺服器的給定目錄中的檔數量,並用圖形來展示它們。
涉及的步驟包括:
在一個元資料檔案中定義將要收集的資料的格式。 定義將在創建檔時進行。 創建收集器腳本,該腳本會在伺服器上收集資訊。 可以使用不同的方法從伺服器中收集資訊,如 HTTP、WCA 等等;我選擇使用腳本,因為它最容易理解。 您還可以通過實現 ICollector 介面來實現自己的 JAVA 類。 由於所有收集器都必須遵從這一介面,因此收集器的回應也必須遵循給定格式。 創建一些腳本,以便在伺服器上上傳元資料檔案和收集器腳本。 我為該角色修改了 install.py 檔。 也可以使用其他方法來實現此功能。 註冊收集器。 要註冊收集器,請使用命令 maestro.monitorAgent.register()。 您應該在 configure.py 檔中執行這個操作。 為使用者介面提供相應配置,以展示所收集資料的圖形表示。 您需要創建一個 monitoring_ui.json 檔來展示該圖形。 該檔應該放在 config.json 檔的旁邊。
根據監控收集器進行伸縮
您添加了一個簡單的收集器來計算某個目錄中檔的數量;接下來,我們將瞭解如何利用這個收集器來根據提供的指標添加伸縮規則。
要實現該場景,需要修改一些檔:
在設計模式時捕捉伸縮規則參數: 要監視的檔目錄。 最小/最大閾值,表示檔的數量。 您希望擴展的虛擬機器的最大/最小數量。 反應時間。 將這些值反映到拓撲中。 更改腳本,創建要監視的目錄,並將參數傳遞給收集器。
必須修改應用程式模型的元資料檔案,從而捕捉伸縮規則的各個參數並定義伸縮策略。 還必須修改 VM 檔,將伸縮策略屬性加入拓撲中。
對於腳本,在前面的小節中,我在腳本中硬編碼了要監視的目錄。 我是在安裝腳本中執行此操作的,但是現在,由於這是一個角色參數,所以必須將它放到角色腳本中,或者將它放到 configure.py 或 start.py 檔中。 顯然,這是一個配置角色,因此需要將它放到配置腳本中。
向操作添加關聯
在模式類型中定義一個角色時,可以將該角色與一些操作關聯起來,以便在部署該模式時啟動這些操作。 在本例中,我向角色添加了一個 「向日志發送字串」 的操作。
要實現某個操作,需要額外添加名為 operation.json 的檔,將它放到 appmodel 目錄中 metadata.json 檔的旁邊。 該檔指定了需要啟動的腳本,而該腳本必須位於 part role 目錄中。
在每個角色的 operation.json 檔中,可以定義大量操作;每個操作都有 id、書簽、描述、分類、腳本和一個屬性清單。 通過使用分類,可以在 UI 中將大量操作組合在一起。 因為該腳本是一個 Python 腳本,所以必須將它放在 role script 目錄中。 屬性會顯示在使用者介面上。
實現一個非常簡單的腳本。 該腳本僅檢索代碼 stringToLog 屬性值,並將它發佈到日誌檔中。 您可以使用下面的語法檢索屬性值:maestro.operation['parms'][{attributeName}];,其中的 attributeName 是您希望檢索的屬性的名稱。 該腳本必須放在 role script 目錄中。
根據作業系統指標進行伸縮
在 前面有關伸縮的段落 中,我介紹了如何使用您自己的監控收集器進行伸縮(計算某個目錄中的檔數量)。 您還可以在一個伸縮策略中重用一些嵌入式 OS 指標。 重用現有的指標要求更改兩個檔:應用程式模型(收集伸縮策略的屬性)和拓撲檔(定義規則並實現該策略)。
在應用程式模型檔中,您需要定義伸縮策略並捕捉該策略的所有屬性。 這非常類似于我們為自己的監控收集器定義策略的情況。 與定義大量檔和一個目錄來監視屬性有所不同,我們將定義一個 cpuUsage 屬性,它是一個百分數。 定義一個用於伺服器角色的策略類型元素。 該策略分兩個部分:一個適用于靜態伸縮策略,另一個適用于基於 CPU 的策略。
對於基於 CPU 的策略,可以定義三個屬性:cpuUsage、scaleInstanceRange1 和 triggerTime1。 您可以自己選擇名稱;注意,該名稱必須與此後定義的屬性清單中的屬性 id 相匹配。 組中的屬性引用的順序定義了在模式編輯器中的顯示順序。
接下來,您需要定義每一個屬性;例如,對於 cpuUsage,可以將它定義為一個範圍,並且必須將它顯示為一個百分數,預設的最小值和最大值分別為 1 和 100。
在拓撲檔中,需要注入在應用程式模型中捕捉到的屬性,使用它們來定義伸縮規則。 此操作是在 VM 檔的 scaling JSON 屬性中完成的。 您可以使用一個 Velocimacro 場景在拓撲中插入元素。
擴展現有的模式類型
一名客戶向我提出下列問題:
我有自己的日誌事件系統,想將 WebSphere® Enterprise Application 環境的所有日誌檔資訊複製到我自己的日誌事件系統中,但又不想為了添加一個新功能而重新創建完整的 WebApp 模式類型。 那麼,我該如何利用現有的 WebApp 模式類型並添加所需的功能?
答案很簡單:擴展 WebApp 模式類型,添加一個外掛程式來執行您所需的功能。 幸運的是,擴展一個模式類型非常簡單。 您只需牢記模式類型是由模式類型定義和大量附加的外掛程式構成的。 每個附加的外掛程式通過各個 config.json 檔中的幾行代碼指定它與模式類型的關係。
您需要做的是創建一個新外掛程式,它將連結到目標模式類型(本例中為 WebApp)。 然後向 metadata.json 檔添加一些新元件。
添加對虛擬應用程式實例進行微調的能力
操作非常重要:它們提供了在已部署的模式或虛擬應用程式上採取相應措施的能力,比如設置參數和根據這些參數進行處理。 啟用一個腳本就可以實現這個目的,該腳本是在應用程式模型中創建的 operation.json 檔中指定的。
操作模型使您通過參數對運行的模式啟用腳本,但也可以使用另一種方法:微調。 兩者的區別在於,微調後的參數可在存儲庫 (storehouse) 中永久保存,可以在所運行模式的生命週期內的任意時間進行重用。
微調在已部署的模式中提供了相同的功能,但是參數可以持久保存。 您可以使用微調參數重新生成一個崩潰的伺服器,並將其設置為早期的版本。 這方面的一個示例是 WebApp 模式中的 WAR/EAR 檔;在將它設置好後,該檔路徑將永久保存到已部署的模式中。
微調後的參數可以連結到元件屬性。
在應用程式模型中,您需要創建 tweak.json 和操作檔。 在 tweak.json 檔中定義您的微調參數。
您可能會問 「如果要進行微調,為什麼還需要一個操作檔」? 您需要使用一個操作檔 ("id": "configuration",),讓使使用者介面顯示 「tweak」。
持久存儲是在 parameters.json 中完成的,該檔位於存儲庫的已部署模式中。
不需要在拓撲檔 (VM) 中進行特殊的處理,除非您希望使用 maestro.parms 函數來檢索值。
在 SmartCloud Application Services 上將儲存體附加到虛擬機器
我曾經考慮過如何將儲存體添加到在 SmartCloud Application Workload Service 上開發的模式類型生成的虛擬機器:事實上,這很簡單。 您只需更新您的拓撲範本來請求儲存體,然後在 vm-templates 陣列元素中引用該儲存體。
使用一個簡單的 VM 檔,通過在 JSON 檔中添加 storage-templates 陣列來添加儲存體請求,通過在 vm-templates 元素中添加一個儲存體陣列元素來添加對該儲存體請求的引用,然後構建您的外掛程式並進行部署。
一旦完成了模式的部署,就可以進行連接並檢查是否已安裝了儲存體,並且該儲存體的大小是否合適。
還要注意的是:SmartCloud Application Workload Service 使用 GB 作為單位來指定其儲存體大小;SmartCloud Enterprise 允許您以 GB 和 TB 為單位發出請求。
結束語
本文簡要介紹了如何在 SmartCloud Application Services 中創建和修改模式類型,希望這篇摘要能夠為您構建可重用的模式類型提供一個良好的開端,虛擬類型是用來創建虛擬模式的構建基礎。 請記住,只要按一下本文提供的連結,便可獲得每個部分的詳細介紹。