為了提供IaaS(虛擬資料中心)服務,我們
支援 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
- 備份
- 統一的配置和配置節點的機制
- 處理虛擬機器元數據
聚苯乙烯 如果您對其他方面感興趣,請寫在評論中。 敬請關注!
來源: www.habr.com