如何建立基準檢驗 Runbook
重要
這個版本的 Orchestrator 已終止支援。 我們建議您 升級至 Orchestrator 2022。
您必須建立效能評定,才能優化 Orchestrator Runbook 的效能。 在建立基準檢驗過程中,您應該分析 Runbook 中的活動。
協調器 Runbook 活動可以視為有兩種不同的程式代碼類型:平臺程式代碼和網域程序代碼。 網域程式碼 一詞可用來識別在通常與 Orchestrator 平台本身無關之 Runbook 活動內的程式碼 (但有明顯的例外,例如 Invoke Runbook、 Junction等等)。 例如,叫用 Web 服務標準活動會包含 Orchestrator 平臺程式代碼 (活動管線) ,以及叫用 SOAP 型 Web 服務的唯一網域程式代碼。 平臺程式代碼對於大部分活動而言非常類似,因為它是以通用架構為基礎所建置。 不過,不同活動的網域程式碼可能會有很大的差異。
資料記錄
數據記錄對 Runbook 效能有重大影響。 為了瞭解效能的目的,請考慮兩個記錄組態:默認記錄和一般已發佈的數據記錄。 每當活動執行時,預設記錄會將大約 524 位元組的資料寫入 Orchestrator 資料庫。 一般已發佈資料記錄則會寫入約 6,082 位元組的資料 (預設記錄層級的 12 倍)。 這些記錄層級之間的效能有顯著的差異。
請試想以下案例:執行相同的 Runbook 活動兩次,一次採用預設層級的資料記錄,另一次則啟用一般已發佈資料記錄。 網域程式碼的完成時間應該相同, 但在啟用一般已發佈資料記錄的情況下,平台程式碼的執行時間將會延長。 基本上,啟用一般已發佈資料時,平台程式碼必須支援比預設記錄層級還多出 12 倍的資料。
標準活動 比較值 可用來建立 Orchestrator 環境的基準檢驗。
建立可用來對 Orchestrator 環境進行效能評定的 Runbook
請遵循下列步驟來建立可用來對 Orchestrator 環境進行基準檢驗的 Runbook:
- 建立新的 Runbook。
- 從 [標準活動] 調色盤新增 Compare Values 活動。 按兩下活動以進行設定。
- 選取 [ 一般 ] 索引標籤,並設定此活動來比較字串 (預設值) 。
- 選取 [詳細數據] 索引標籤,在 [測試] 方塊中輸入 STRING 值,然後選取為空白。
- 選取 [完成 ] 以將更新儲存至活動。
- 在活動上按一下滑鼠右鍵並選取 [迴圈] 。
- 針對 [兩次嘗試的延遲間隔] 選取 [啟用] 核取方塊並輸入數字 0(零)。
- 選取 [ 結束] 索引標籤 。
- 變更預設的結束條件。 選取 [比較值],核取 [ 顯示一般已發佈數據 ] 複選框,然後選取 [迴圈:嘗試次數]。 選取 [確定 ] 以儲存此變更。
- 從更新的結束條件中選取 值 ,然後輸入數位 10000 (千) 。 選取 [確定 ] 以儲存此變更。
- 選取 [完成] 以儲存這些更新。
- 選取 [簽到],將變更儲存至 Orchestrator 資料庫。
這個單一活動的簡單 Runbook 將會執行「比較值」 活動 10,000 次。 「比較值」 是網域程式碼極少的簡單活動。 您可以在各種情況下叫用此 Runbook,以便歸納指定之 Orchestrator 執行階段環境的整體效能。
此 Runbook 可用來實驗不同的 Orchestrator 設定。 例如,假設您要判斷四部部署在不同資料中心內的 Runbook 伺服器效能。
資料中心 | 記錄設定 | 平台程式碼執行時間 (秒) | 毫秒/活動 | 擴充係數 |
---|---|---|---|---|
位置 1 | 預設記錄 | 819 | 82 | 1.0 (參考) |
位置 1 | 記錄一般已發佈資料 | 2012 | 201 | 2.5 |
位置 2 | 預設記錄 | 1229 | 123 | 1.5 |
位置 2 | 記錄一般已發佈資料 | 3686 | 369 | 4.5 |
位置 3 | 預設記錄 | 2457 | 426 | 3.0 |
位置 3 | 記錄一般已發佈資料 | 4422 | 442 | 5.4 |
位置 4 | 預設記錄 | 1474 | 147 | 1.8 |
位置 4 | 記錄一般已發佈資料 | 2654 | 265 | 3.2 |
請注意由記錄一般已發佈資料所造成平台效能大幅降低的現象。 最差的情況發生在位置 2 的一般已發佈資料記錄作業。 在表面上,這個現象似乎是明確而相關的結論。
不過請注意,這些圖表反映的是平台程式碼的負荷,不是網域程式碼。 網域程式碼的執行階段可能會大幅延長。 例如,Virtual Machine Manager 整合套件中的「從範本建立 VM」 活動可能會在建立 VM 時執行數分鐘之久。 從上述案例延伸,請試想不論位置為何,執行時間均為 1 分鐘 (1 分鐘 = 60,000 毫秒) 之 Runbook 活動的平台程式碼成本。
資料中心 | 記錄設定 | 平台程式碼執行時間 (秒) | 網域程式碼 % | 平台程式碼 % |
---|---|---|---|---|
位置 1 | 預設記錄 | 819 | 98.6% | 1.4% |
位置 1 | 記錄一般已發佈資料 | 2012 | 96.7% | 3.3% |
位置 2 | 預設記錄 | 1229 | 98.0% | 2.0% |
位置 2 | 記錄一般已發佈資料 | 3686 | 93.9% | 6.1% |
位置 3 | 預設記錄 | 2457 | 95.9% | 4.1% |
位置 3 | 記錄一般已發佈資料 | 4422 | 92.6% | 7.4% |
位置 4 | 預設記錄 | 1474 | 97.5% | 2.5% |
位置 4 | 記錄一般已發佈資料 | 2654 | 95.6% | 4.4% |
這些資料所代表的意義逐漸成形。 在位置 2 啟用一般已發佈資料記錄的案例蟬聯效能表現最差的案例。 不過,平台程式碼和記錄作業僅佔總執行時間的 6%。 儘管如此,這個數字仍然偏高,因為表現最好的案例只佔了 1.4%。 基本上,此範例花在網域程式碼的時間比花在執行平台程式碼的時間多出許多。 若要將此概觀化,如果您能夠完全消除平台程序代碼成本,則只會在 1.4% 到 7.4% 的範圍內看到 Runbook 效能改善。
當然,大部分的實際案例都會不同。 活動行為可能會因網域程式碼接獲的作業指示不同而改變。 例如, 從範本複製 VM 活動可能需要一分鐘的時間,才能從伺服器範本 A 複製 VM,但需要 5 分鐘才能從伺服器範本 B 複製 VM。此外,Runbook 伺服器可能位於具有不同效能特性的不同網路上,這可能會影響網域程式代碼效能,以及 Orchestrator 資料記錄效能。
總結來說:
- 請謹慎拿捏已發佈資料的記錄時機。
- 請仔細評估記錄一般已發佈資料所造成的影響。 請切記記錄的資料數量取決於活動執行的次數。 活動數目較少但執行次數較多的 Runbook,其資料記錄數量可能比執行次數較少但較大型的 Runbook 還多。
- 請勿在生產環境中啟用活動特定已發佈數據的記錄。
- 請設法瞭解 Runbook 在執行網域程式碼和平台程式碼時所需時間的差異。
- 請使用本文件概述的技術來預估平台程式碼成本。 請參考這些技術,考量您應從何處著手改善 Runbook 的效能。
- 請使用本文件概述的技術來深入瞭解不同執行階段環境的相對效能。 請採用標準的測量比較方式,藉此找出改進的機會。
下一步
在 建立及測試範例 Runbook 中取得建立 Runbook 的逐步指示。
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應