为了提供IaaS（虚拟数据中心）服务，我们 我们使用商业协调器 （英国外交部）。 该解决方案具有相当独特的架构，这使其有别于公众所熟知的Openstack和CloudStack。
支持 KVM、VmWare、Xen、Virtuozzo6/7 以及来自同一 Virtuozzo 的容器作为计算节点管理程序。 支持的存储选项包括本地、NFS、Ceph 和 Virtuozzo 存储。
FCO 支持从单个界面创建和管理多个集群。 也就是说，您可以通过单击鼠标在 Virtuozzo 集群和 KVM + Ceph 集群之间进行切换来管理它们。
FCO 的核心是面向云提供商的综合解决方案，除了编排之外，还包括计费、所有设置、支付插件、发票、通知、经销商、关税等。 然而，计费部分无法涵盖俄罗斯的所有细微差别，因此我们放弃了它的使用，转而采用另一种解决方案。
我对用于向所有云资源分配权限的灵活系统感到非常满意：图像、磁盘、产品、服务器、防火墙 - 所有这些都可以在用户之间甚至不同客户端的用户之间“共享”和授予权限。 每个客户都可以在其云中创建多个独立的数据中心，并通过单个控制面板对其进行管理。
从架构上来说，FCO由几个部分组成，每个部分都有自己独立的代码，有的还有自己的数据库。
蓝天 – 管理和用户界面
Jade – 业务逻辑、计费、任务管理
Tigerlily的 – 服务协调员，管理和协调业务逻辑和集群之间的信息交换。
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
- 备份
- 统一的配置和配置节点的机制
- 处理虚拟机元数据
ZY 如果您对其他方面感兴趣，请写在评论中。 敬请关注！
来源： habr.com