为了提供IaaS（虚拟数据中心）服务，我们在
Rusonyx使用
Flexiant Cloud Orchestrator （FCO）商业乐队。 该解决方案具有相当独特的架构，使它与众所周知的Openstack和CloudStack区别开来。
作为计算节点系统管理程序，支持KVM，VmWare，Xen，Virtuozzo6 / 7，以及来自同一Virtuozzo的容器。 在受支持的存储中-本地，NFS，Ceph和Virtuozzo存储。
FCO支持从单个界面创建和管理多个集群。 也就是说，您可以通过单击鼠标在Virtuozzo群集和KVM + Ceph群集之间进行切换来管理它们。
从本质上讲，FCO是针对云提供商的全面解决方案，除了业务流程编排之外，FCO还包括计费，所有设置，支付插件，帐户，通知，转销商，费率等。 但是，计费部分无法涵盖俄罗斯的所有细微差别，因此我们拒绝将其用于其他解决方案。
灵活的将权限分配给所有云资源的系统非常令人愉悦：映像，磁盘，产品，服务器，防火墙-所有这些都可以被弄乱并在用户之间甚至不同客户端的用户之间授予权限。 每个客户都可以在其云中创建几个独立的数据中心，并通过一个控制面板对其进行管理。
从结构上讲，FCO由几个部分组成，每个部分都有自己的独立代码，而有些则有自己的数据库。
Skyline-管理员和用户界面
Jade-业务逻辑，计费，任务管理
Tigerlily是服务协调员，负责管理和协调业务逻辑和集群之间的信息交换。
XVPManager-群集元素的管理：节点，存储，网络和虚拟机。
XVPAgent-安装在节点上以与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中的视频直接嵌入用户界面中。
所有定制均以基于Lua的FDL语言编写。 如果您知道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”参数存储通话竞赛，并且在第一次通话时将为空（无）。 这将使我们能够注册触发器。 在triggerType中，我们显示触发器在发布操作之前被称为，并且仅适用于用户。 当然，对于系统管理员，我们允许发布所有内容。 在triggerOptions中，我们详细说明了将触发触发器的操作。
最重要的是，返回{exitState =“ CANCEL”}，这就是开发触发器的原因。 当用户尝试在控制面板中共享其图像时，它将返回失败。
在FCO架构中，任何对象（磁盘，服务器，映像，网络，网络适配器等）都表示为具有公共参数的Resource实体：
- 资源uuid
- 资源名称
- 资源类型
- 资源所有者UUID
- 资源状态（活动，非活动）
- 资源元数据
- 资源密钥
- 资源所属产品的UUID
- VDC资源
当使用API时，如果使用相同的原理来处理所有资源，这将非常方便。 产品由提供商配置，然后客户订购。 由于我们的帐单是场外交易，因此客户可以从面板上免费订购任何产品。 稍后会在结算中考虑。 产品可能是-每小时ip地址，每小时额外的GB磁盘或仅一台服务器。
您可以使用键标记某些资源，以更改使用它们的逻辑。 例如，我们可以用权重键标记三个物理节点，并用相同的键标记某些客户端，从而为这些客户端亲自突出显示这些节点。 对于不喜欢虚拟机旁边的邻居的VIP客户，我们使用这种机制。 该功能本身可以更广泛地应用。
许可模型意味着为物理节点的处理器的每个核心付费。 成本还受到群集类型数量的影响。 如果计划一起使用（例如，KVM和VMware），则许可证的成本将增加。
FCO是成熟的产品，其功能非常丰富，因此我们计划一次准备几篇文章，并详细描述网络部分的功能。
与该乐队合作了几年，我们可以将其标记为非常合适。 las，该产品并非没有缺陷：
- 我们必须优化数据库，因为查询随着数据量的增加而开始放缓。
- 一次事故后，由于错误，恢复机制无法正常工作，我们不得不使用自己的脚本来提高不满意客户的机器；
- 节点不可访问性检测机制已连接到代码中，无法自定义。 也就是说，我们无法创建自己的策略来确定节点的不可访问性。
- 日志记录并不总是很详细。 有时，当您需要降到很低的水平来分析特定问题时，某些组件的源代码不足以理解原因；
总计：总体而言，产品体验很好。 我们一直与乐团的开发者保持联系。 这些家伙被安排进行建设性合作。
尽管简单，但FCO具有广泛的功能。 在以后的文章中，我们计划深入探讨以下主题：
- 在FCO建立网络
- 实时恢复和FQP协议支持
- 编写自定义插件和小部件
- 连接其他服务，例如负载均衡器和Acronis
- 后备
- 节点配置和配置的统一机制
- 虚拟机元数据处理
PS如果其他方面有趣，请在评论中写下。 敬请期待！