您好，Khabrovchans！ 我们将继续为您提供俄罗斯超融合系统AERODISK vAIR。 本文将重点介绍此系统的体系结构。 在上一篇文章中，我们分析了ARDFS文件系统，在本文中，我们将介绍构成vAIR及其任务的所有主要软件组件。
我们从下至上开始对架构进行描述-从存储到管理。
ARDFS + Raft群集驱动程序文件系统
vAIR的基础是分布式文件系统ARDFS，该系统将所有群集节点的本地磁盘组合到一个逻辑池中，在此基础上由4MB虚拟块形成具有一个或另一种容错方案（复制因子或擦除编码）的虚拟磁盘。 上一篇文章对ARDFS的工作进行了更详细的描述。
Raft Cluster Driver是一项内部ARDFS服务，它解决了文件系统元数据的分布式和可靠存储问题。
ARDFS元数据通常分为两类。
- 通知-有关存储对象操作的信息以及有关对象本身的信息；
- 服务信息-设置存储节点的锁定和配置信息。
RCD服务用于分发此数据。 它自动分配一个具有领导者角色的节点，其任务是在节点上获取和传播元数据。 领导者是此信息的唯一真实来源。 此外，领导者还可以组织心跳，即 检查所有存储节点的可用性（这与虚拟机的可用性无关，RCD只是用于存储的服务）。
如果由于任何原因领导者对于一个普通节点之一变得不可用超过一秒钟，则该普通节点将重新组织领导者，从而要求其他普通节点提供领导者的可用性。 如果达到法定人数，则再次当选组长。 前领导人“醒来”后，他自动成为普通节点，因为 新的领导者会给他适当的团队。
RCD本身的逻辑并不新鲜。 许多第三方，商业和免费解决方案也遵循此逻辑，但是这些解决方案不适合我们（例如现有的开源FS），因为它们很笨重，并且很难为我们的简单任务对其进行优化，因此我们只编写了自己的解决方案RCD服务。
领导者似乎是“脖子狭窄”的人，可以使大型集群中的数百个节点的工作速度减慢，但事实并非如此。 自从我们自己编写并仅包含最必要的功能以来，所描述的过程几乎立即发生，并且“称量”很小。 此外，它完全自动发生，仅在日志中保留消息。
MasterIO-多线程I / O管理服务
一旦组织了带有虚拟磁盘的ARDFS池，就可以将其用于I / O。 此时，这个问题专门针对超融合系统出现，即：我们可以为IO捐赠多少系统资源（CPU / RAM）？
在传统的存储系统中，这个问题并不那么尖锐，因为存储任务仅用于存储数据（并且大多数系统存储资源都可以在IO下安全地分配），并且除存储之外的超融合任务还包括虚拟机的执行。 因此，GCS要求主要为虚拟机使用CPU和RAM资源。 好吧，I / O呢？
为了解决此问题，vAIR使用I / O管理服务：MasterIO。 该服务的任务很简单- “承担一切并分享” 确保可以获取第n个用于输入和输出的系统资源，并从它们开始启动第n个输入/输出流。
最初，我们想提供一种“非常聪明”的机制来为IO分配资源。 例如，如果存储设备上没有负载，则可以将系统资源用于虚拟机，如果出现负载，则在预定限制内从虚拟机“软”删除这些资源。 但是这种尝试以部分失败而告终。 测试表明，如果负载逐渐增加，则一切正常，资源（标记为可能删除）逐渐从VM撤出，转而支持I / O。 但是急剧的存储负载激起了虚拟机资源的“软”撤退，结果，队列在处理器上积累，结果， 狼饿了，羊死了 和virtualka挂起，并且没有IOPS。
也许将来我们会回到这个问题上来，但是现在我们已经以一种很好的祖父方式实现了IO的资源发行。
基于大小调整数据，管理员为MasterIO服务预分配了第n个CPU内核和RAM。 这些资源被分配为垄断，即 除非管理员允许，否则它们不能以任何方式用于VM的需求。 资源平均分配，即 从群集的每个节点获取相同数量的系统资源。 首先，处理器资源是MasterIO感兴趣的（RAM不太重要），特别是如果我们使用擦除编码。
如果在调整大小时发生错误，并且我们将太多资源分配给MasterIO，则可以通过将这些资源移回VM资源池来轻松解决这种情况。 如果资源处于空闲状态，则它们几乎将立即返回到VM资源池，但是如果这些资源被处理掉，则必须等待一段时间，MasterIO才能软释放它们。
相反的情况则更为复杂。 如果我们需要增加MasterIO的内核数量，并且它们忙于虚拟机，那么我们就必须与虚拟机“协商”，即选择它们与句柄，因为在自动模式下，如果负载急剧增加，此操作将充满VM冻结和其他反复无常的行为。
因此，在确定IO超融合系统（不仅是我们的系统）的性能时，需要引起很多关注。 在其中一篇文章的稍后，我们承诺会更详细地考虑这个问题。
管理程序
Hypervisor Aist负责在vAIR中运行虚拟机。 该管理程序基于经过时间考验的KVM管理程序。 原则上，关于KVM的工作已经写了很多，因此没有特别的必要，只需指出KVM的所有标准功能都存储在Stork中就可以了。
因此，在这里我们将描述与在Stork中实现的标准KVM的主要区别。 鹳是系统的一部分（预安装的管理程序），可通过Web-GUI（俄语和英语版本）和SSH（显然只有英语）从vAIR通用控制台进行控制。
此外，系统管理程序配置存储在分布式ConfigDB数据库中（稍后再介绍），这也是一个控制点。 也就是说，您可以连接到群集中的任何节点并管理所有节点，而无需单独的管理服务器。
我们开发的HA模块是标准KVM功能的重要补充。 这是高可用性虚拟机群集的最简单实现，允许您在节点发生故障时自动在另一个群集节点上重新启动虚拟机。
另一个有用的功能是虚拟机的大规模部署（与VDI环境相关），这将根据节点之间的负载自动部署虚拟机，并在节点之间自动分配虚拟机。
节点之间的VM分配是自动负载平衡（ala DRS）的基础。 该功能在当前版本中尚不可用，但是我们正在积极地研究它，它肯定会出现在下一个更新中。
可选地支持VMware ESXi虚拟机管理程序，当前它是使用iSCSI协议实现的，并且将来也计划支持NFS。
虚拟交换机
对于交换机的软件实现，提供了一个单独的组件-Fractal。 与其他组件一样，我们也从简单过渡到复杂，因此在第一个版本中，实现了简单的交换，同时为第三方设备提供了路由和防火墙。 操作原理是标准的。 服务器的物理接口通过网桥连接到Fractal对象（一组端口）。 一组端口，依次包含集群中所需的虚拟机。 支持VLAN的组织，并且在下一版本中，将添加VxLAN支持。 默认情况下，所有创建的开关都是分布式的，即 分布在群集的所有节点上，因此哪些交换机连接到VM的虚拟机不依赖于位置节点，这仅是管理员的决定。
监测与统计
实际上，负责监视和统计的组件（工作名称Monica）是从ENGINE存储系统重新设计的克隆。 一次，他的自我推荐很好，我们决定将其与vAIR一起轻松调整。 像所有其他组件一样，Monica同时执行并存储在群集的所有节点上。
莫妮卡的艰巨职责概述如下：
资料收集：
- 来自硬件传感器（可以通过IPMI产生铁的传感器）；
- 来自vAIR逻辑对象（ARDFS，Stork，Fractal，MasterIO和其他对象）。
在分布式数据库中收集数据；
数据解释的形式为：
通过SMTP（发送电子邮件警报）和SNMP（与第三方监视系统的交互）协议与第三方系统进行外部交互。
分布式配置库
在前面的段落中，提到了许多数据同时存储在集群的所有节点上。 为了组织这种存储方法，提供了一个特殊的分布式ConfigDB数据库。 顾名思义，该数据库存储所有群集对象的配置：虚拟机监控程序，虚拟机，HA模块，交换机，文件系统（不要与FS元数据数据库混淆，这是另一个数据库）以及统计信息。 此数据同步存储在所有节点上，并且此数据的一致性是vAIR稳定运行的前提。
重要一点：尽管ConfigDB的功能对于vAIR操作至关重要，但其故障虽然会停止集群，但不会影响存储在ARDFS中的数据的一致性，我们认为这是整体解决方案可靠性的一个加分。
ConfigDB也是单点管理，因此您可以通过IP地址访问群集的任何节点，并完全管理群集的所有节点，这非常方便。
此外，对于访问外部系统，ConfigDB提供了Restful API，通过它您可以配置与第三方系统的集成。 例如，我们最近在VDI和信息安全领域与几种俄罗斯解决方案进行了试点集成。 项目完成后，我们将很乐意在此处编写技术详细信息。
整个图片
结果，我们有两个版本的系统架构。
在第一种情况（主要情况）中，使用了基于KVM的Aist虚拟机管理程序和Fractal软件开关。
方案1.正确
在第二个（可选选项）中，当您要使用ESXi虚拟机管理程序时，该方案有些复杂。 为了使用ESXi，必须以标准方式将其安装在群集的本地驱动器上。 接下来，在每个ESXi节点上，安装vAIR MasterVM虚拟机，其中包含一个特殊的vAIR发行版，可以作为VMware虚拟机运行。
ESXi通过直接转发到MasterVM来提供所有可用的本地磁盘。 在MasterVM内部，这些磁盘已经按照ARDFS标准进行了格式化，并使用iSCSI协议（将来还会有NFS）通过专用于ESXi的接口传送到外部（或更确切地说，又回到了ESXi）。 因此，在这种情况下，虚拟机和软件网络由ESXi提供。
方案2. ESXi
因此，我们拆解了vAIR体系结构的所有主要组件及其任务。 在下一篇文章中，我们将讨论已经实现的功能和不久的将来的计划。
我们正在等待评论和建议。