為了提供IaaS（虛擬資料中心）服務，我們 我們使用商業協調器 （英國外交部）。 該解決方案具有相當獨特的架構，使其有別於大眾所熟知的Openstack和CloudStack。
支援 KVM、VmWare、Xen、Virtuozzo6/7 以及來自相同 Virtuozzo 的容器作為計算節點管理程式。 支援的儲存選項包括本機、NFS、Ceph 和 Virtuozzo 儲存。
FCO 支援從單一介面建立和管理多個叢集。 也就是說，您可以透過點擊滑鼠在 Virtuozzo 叢集和 KVM + Ceph 叢集之間進行切換來管理它們。
FCO 的核心是雲端供應商的綜合解決方案，除了編排之外，還包括計費、所有設定、支付插件、發票、通知、經銷商、關稅等。 然而，計費部分無法涵蓋俄羅斯的所有細微差別，因此我們放棄了它的使用，轉而採用另一種解決方案。
我對用於向所有雲端資源分配權限的靈活系統感到非常滿意：映像、磁碟、產品、伺服器、防火牆 - 所有這些都可以在使用者之間甚至不同客戶端的使用者之間「共享」和授予權限。 每個客戶都可以在其雲端中建立多個獨立的資料中心，並透過單一控制面板對其進行管理。
從架構上來說，FCO由幾個部分組成，每個部分都有自己獨立的程式碼，有的還有自己的資料庫。
藍天 – 管理和使用者介面
玫瑰粉晶按摩滾輪 – 業務邏輯、計費、任務管理
老虎莉莉 – 服務協調員，管理和協調業務邏輯和叢集之間的資訊交換。
XVP經理 – 叢集元素的管理：節點、儲存、網路和虛擬機器。
XVPA代理 – 安裝在節點上與 XVPManager 互動的代理
當然，如果該主題引起人們的興趣，我們計劃在一系列文章中包含有關每個組件架構的詳細故事。
FCO 的主要優勢源自於其「盒裝」性質。 簡單和極簡主義為您服務。 對於控制節點，分配了一台 Ubuntu 虛擬機，其中安裝了所有必要的軟體包。 所有設定都以變數值的形式放置在設定檔中：
# cat /etc/extility/config/vars
…
export LIMIT_MAX_LIST_ADMIN_DEFAULT="30000"
export LIMIT_MAX_LIST_USER_DEFAULT="200"
export LOGDIR="/var/log/extility"
export LOG_FILE="misc.log"
export LOG_FILE_LOG4JHOSTBILLMODULE="hostbillmodule.log"
export LOG_FILE_LOG4JJADE="jade.log"
export LOG_FILE_LOG4JTL="tigerlily.log"
export LOG_FILE_LOG4JXVP="xvpmanager.log"
export LOG_FILE_VARS="misc.log"
…
整個配置最初在模板中編輯，然後啟動生成器
#build-config 它將產生一個 vars 檔案並命令服務重新讀取配置。 使用者介面很好，並且可以輕鬆品牌化。
正如您所看到的，該介面由用戶可以控制的小部件組成。 他可以輕鬆地從頁面添加/刪除小部件，從而創建他需要的儀表板。
儘管 FCO 具有封閉性，但它是一個高度可自訂的系統。 它有大量用於更改工作流程的設定和入口點：
- 支援自訂插件，例如您可以編寫自己的計費方式或自己的外部資源來為使用者提供
- 支援某些事件的自訂觸發器，例如，在建立客戶端時將第一個虛擬機器新增至客戶端
- 支援介面中的自訂小工具，例如，將 YouTube 影片直接嵌入到使用者介面中。
所有自訂都是用 FDL 編寫的，FDL 是基於 Lua 的。 如果你了解Lua，那麼FDL就不會有問題。
這是我們使用的最簡單觸發器之一的範例。 此觸發器不允許使用者與其他客戶端共用自己的映像。 我們這樣做是為了防止一個用戶為其他用戶創建惡意圖像。
function register()
return {"pre_user_api_publish"}
end
function pre_user_api_publish(p)
if(p==nil) then
return{
ref = "cancelPublishImage",
name = "Cancel publishing",
description = "Cancel all user’s images publishing",
triggerType = "PRE_USER_API_CALL",
triggerOptions = {"publishResource", "publishImage"},
api = "TRIGGER",
version = 1,
}
end
-- Turn publishing off
return {exitState = "CANCEL"}
end
寄存器函數將由 FCO 內核呼叫。 它將傳回要呼叫的函數的名稱。 該函數的“p”參數存儲調用上下文，第一次調用時它將為空（nil）。 這將允許我們註冊我們的觸發器。 在triggerType中，我們指示觸發器在發布操作之前調用，並且僅影響使用者。 當然，我們允許系統管理員發布所有內容。 在triggerOptions中，我們詳細說明了觸發器將觸發的操作。
而最主要的是return {exitState = “CANCEL”}，這就是觸發器被開發的原因。 當用戶嘗試在控制面板中共享其圖像時，它將返回失敗。
在FCO架構中，任何物件（磁碟、伺服器、映像、網路、網路介面卡等）都被表示為Resource實體，它具有共同的參數：
- 資源UUID
- 資源名稱
- 資源類型
- 資源所有者 UUID
- 資源狀態（活動、非活動）
- 資源元數據
- 資源鍵
- 擁有資源的產品的 UUID
- 資源VDC
當使用 API 工作時，當所有資源都按照相同的原理運作時，這非常方便。 產品由提供者配置並由客戶訂購。 由於我們的計費是側向的，客戶可以自由地從面板訂購任何產品。 稍後在計費時計算。 該產品可以是每小時一個 IP 位址、每小時額外 GB 的磁碟，或只是一台伺服器。
鍵可用於標記某些資源以變更使用它們的邏輯。 例如，我們可以用Weight鍵標記三個實體節點，並用相同的鍵標記一些客戶端，從而將這些節點單獨指派給這些客戶端。 我們為不喜歡虛擬機器旁邊的鄰居的 VIP 用戶端使用此機制。 該功能本身可以被更廣泛地使用。
許可模式涉及為實體節點的每個處理器核心付費。 成本也受到集群類型數量的影響。 例如，如果您打算同時使用 KVM 和 VMware，則授權的成本將會增加。
FCO是一個成熟的產品，它的功能非常豐富，所以我們計劃一次準備幾篇文章，詳細描述網路部分的功能。
我們與這個編排器合作了幾年，可以認為它非常合適。 可惜的是，該產品並非沒有缺陷：
- 我們必須優化資料庫，因為隨著資料量的增加，查詢開始變慢；
- 一次事故後，恢復機制由於錯誤而無法工作，我們不得不使用我們自己的一組腳本來恢復不幸客戶的汽車；
- 偵測節點不可用性的機制已硬連線到程式碼中，無法自訂。 也就是說，我們無法創建自己的策略來確定節點的不可用性。
- 日誌記錄並不總是詳細的。 有時，當您需要深入到非常低的層級來理解特定問題時，您沒有足夠的原始程式碼來讓某些元件理解原因；
總計： 整體而言，產品的印象良好。 我們與協調器開發人員保持持續聯繫。 這些傢伙願意進行建設性合作。
儘管 FCO 很簡單，但它具有廣泛的功能。 在未來的文章中，我們計劃更深入地探討以下主題：
- FCO 網路
- 提供即時恢復和FQP協議
- 編寫您自己的插件和小部件
- 連線附加服務，例如負載平衡器和 Acronis
- 備份
- 統一的配置和配置節點的機制
- 處理虛擬機器元數據
Z.Y. 如果您對其他方面感興趣，請寫在評論中。 敬請關注！
來源： www.habr.com