你好，哈布尔的读者。 在本文中，我们开启了一个系列，将讨论我们开发的超融合系统 AERODISK vAIR。 最初，我们想在第一篇文章中讲述所有内容，但系统相当复杂，所以我们将把大象分成几部分。
让我们从系统创建的历史开始讲故事，深入研究作为 vAIR 基础的 ARDFS 文件系统，同时也谈谈这个解决方案在俄罗斯市场的定位。
在以后的文章中，我们将更详细地讨论不同的架构组件（集群、管理程序、负载均衡器、监控系统等）、配置过程、提出许可问题、单独展示崩溃测试，当然，还会撰写有关负载测试和浆纱。 我们还将专门撰写一篇文章来介绍 vAIR 的社区版本。
Aerodisk 是一个关于存储系统的故事吗？ 或者说我们一开始为什么要开始做超融合？
最初，我们在 2010 年左右萌生了创建自己的超融合的想法。 当时，市场上既没有 Aerodisk，也没有类似的解决方案（商业盒装超融合系统）。 我们的任务如下：从一组带有本地磁盘的服务器，通过以太网协议通过互连联合起来，有必要创建一个扩展存储并在那里启动虚拟机和软件网络。 所有这一切都必须在没有存储系统的情况下实现（因为根本没有钱购买存储系统及其硬件，而且我们还没有发明自己的存储系统）。
我们尝试了很多开源解决方案，最终解决了这个问题，但解决方案非常复杂，难以重复。 此外，该解决方案属于“它有效吗？”的类别。 别碰！ 因此，在解决了这个问题之后，我们并没有进一步发展将我们的工作成果转化为成熟产品的想法。
那次事件之后，我们放弃了这个想法，但我们仍然感觉这个问题是完全可以解决的，而且这种解决方案的好处是显而易见的。 随后国外公司发布的HCI产品也更加印证了这种感觉。
因此，在 2016 年中期，我们重新开始执行此任务，作为创建成熟产品的一部分。 当时我们还没有和投资者建立任何关系，所以我们只能用自己不多的钱去买一个开发台。 收集完 Avito 上使用过的服务器和交换机后，我们开始做正事。
最初的主要任务是创建我们自己的文件系统，虽然很简单，但是我们自己的文件系统，它可以以虚拟块的形式自动均匀地将数据分布在第 n 个集群节点上，这些节点通过以太网互连进行连接。 同时，FS应该能够良好且轻松地扩展，并且独立于相邻系统，即以“只是一个存储设施”的形式与 vAIR 疏远。
第一个 vAIR 概念
我们故意放弃使用现成的开源解决方案来组织扩展存储（ceph、gluster、lustre 等），转而支持我们自己的开发，因为我们已经拥有了很多使用它们的项目经验。 当然，这些解决方案本身非常出色，在开发 Aerodisk 之前，我们与它们实施了多个集成项目。 但是，为一个客户实施特定任务、培训员工，或许还需要购买大型供应商的支持是一回事，而创建一种易于复制的产品，用于各种任务，则是另一回事，我们作为一个供应商，甚至可能了解我们自己，但我们不会。 对于第二个目的，现有的开源产品不适合我们，所以我们决定自己创建一个分布式文件系统。
两年后，几位开发人员（将 vAIR 的工作与经典 Engine 存储系统的工作结合起来）取得了一定的成果。
到 2018 年，我们已经编写了一个简单的文件系统，并补充了必要的硬件。 系统通过内部互连将来自不同服务器的物理（本地）磁盘组合成一个扁平池，并将它们“切割”成虚拟块，然后从虚拟块创建具有不同容错程度的块设备，并在虚拟块上创建虚拟块设备。并使用 KVM 管理程序汽车执行。
我们没有过多考虑文件系统的名称，简单地将其称为 ARDFS（猜猜它代表什么））
这个原型看起来不错（当然不是视觉上的，当时还没有视觉设计），并且在性能和扩展方面表现出了良好的效果。 在获得第一个实际结果后，我们启动了该项目，组织了一个成熟的开发环境和一个仅处理 vAIR 的独立团队。
那时解决方案的总体架构已经成熟，尚未发生重大变化。
深入探讨 ARDFS 文件系统
ARDFS 是 vAIR 的基础，它在整个集群中提供分布式、容错的数据存储。 ARDFS 的显着特征之一（但不是唯一）是它不使用任何额外的专用服务器进行元数据和管理。 最初的设想是为了简化解决方案的配置并提高其可靠性。
存储结构
在集群的所有节点中，ARDFS 从所有可用磁盘空间组织一个逻辑池。 重要的是要理解池还不是数据或格式化空间，而只是标记，即任何安装了 vAIR 的节点在添加到集群时，都会自动添加到共享 ARDFS 池中，并且磁盘资源会自动在整个集群中共享（并可用于将来的数据存储）。 这种方法允许您动态添加和删除节点，而不会对已经运行的系统产生任何严重影响。 那些。 该系统非常容易“以砖块形式”扩展，如有必要，可以添加或删除集群中的节点。
虚拟磁盘（虚拟机的存储对象）添加到 ARDFS 池的顶部，该池由 4 MB 大小的虚拟块构建。 虚拟磁盘直接存储数据。 容错方案也是在虚拟磁盘级别设置的。
你可能已经猜到了，为了磁盘子系统的容错，我们没有使用RAID（独立磁盘冗余阵列）的概念，而是使用RAIN（独立节点冗余阵列）。 那些。 容错是基于节点而不是磁盘来测量、自动化和管理的。 当然，磁盘也是一个存储对象，它们像其他所有东西一样受到监控，您可以使用它们执行所有标准操作，包括组装本地硬件 RAID，但集群专门在节点上运行。
在您确实需要 RAID 的情况下（例如，支持小型集群上的多个故障的场景），没有什么可以阻止您使用本地 RAID 控制器，并在顶部构建延伸存储和 RAIN 架构。 这种场景非常活跃并且得到了我们的支持，因此我们将在一篇有关使用 vAIR 的典型场景的文章中讨论它。
存储容错方案
vAIR 中的虚拟磁盘可以有两种容错方案：
1）复制因子或简单的复制——这种容错方法就像一根棍子和一根绳子一样简单。 同步复制在节点之间执行，因子为 2（每个集群 2 个副本）或 3（分别为 3 个副本）。 RF-2 允许虚拟磁盘承受集群中 3 个节点的故障，但“吃掉”一半的有用卷，而 RF-2 将承受集群中 2 个节点的故障，但保留 3/1 的可用卷。满足其需要的有用体积。 该方案与RAID-2非常相似，即RF-XNUMX中配置的虚拟磁盘可以抵抗集群中任何一个节点的故障。 在这种情况下，数据一切正常，甚至 I/O 也不会停止。 当故障节点恢复服务时，将开始自动数据恢复/同步。
以下是正常模式和故障情况下 RF-2 和 RF-3 数据分布的示例。
我们有一个虚拟机，其独特（有用）数据容量为 8MB，该虚拟机在 4 个 vAIR 节点上运行。 显然，现实中不太可能有这么小的体积，但对于反映ARDFS运行逻辑的方案来说，这个例子是最容易理解的。 AB 是包含唯一虚拟机数据的 4MB 虚拟块。 RF-2 分别创建这些块 A1+A2 和 B1+B2 的两个副本。 这些块是跨节点“布局”的，避免了同一节点上相同数据的交集，即副本A1不会与副本A2位于同一节点。 与B1和B2相同。
如果其中一个节点发生故障（例如，3 号节点，其中包含 B1 的副本），则该副本会在没有其副本（即 B2 的副本）的节点上自动激活。
因此，虚拟磁盘（以及相应的 VM）可以轻松地在 RF-2 方案中的一个节点发生故障时幸存下来。
复制方案虽然简单可靠，但也存在与 RAID1 相同的问题 - 可用空间不足。
2)纠删码或纠删码(也称为“冗余编码”、“纠删码”或“冗余码”)就是为了解决上述问题而存在的。 EC 是一种冗余方案，与复制相比，它提供了高数据可用性和更低的磁盘空间开销。 该机制的工作原理与RAID 5、6、6P类似。
编码时，EC 进程根据 EC 方案将虚拟块（默认为 4MB）划分为几个较小的“数据块”（例如，2+1 方案将每个 4MB 块划分为 2 个 2MB 块）。 接下来，该过程为不大于先前划分的部分之一的“数据块”生成“奇偶校验块”。 解码时，EC 通过读取整个集群中“幸存”的数据来生成丢失的块。
例如，采用2+1 EC方案的虚拟磁盘，在4个集群节点上实现，将像RF-2一样轻松承受集群中一个节点的故障。 在这种情况下，管理费用会更低，特别是，RF-2 的有用容量系数为2，EC 2+1 的有用容量系数为1,5。
简单描述一下，本质就是将虚拟块划分为2-8个（为什么是2到8个，见下文）“块”，并为这些块计算相似体积的奇偶校验“块”。
因此，数据和奇偶校验均匀分布在集群的所有节点上。 同时，与复制一样，ARDFS自动在节点之间分配数据，以防止相同的数据（数据副本及其奇偶校验）存储在同一节点上，以消除由于数据丢失而丢失数据的机会。事实上，数据及其奇偶校验将突然出现在一个发生故障的存储节点上。
下面是一个示例，具有相同的 8 MB 虚拟机和 4 个节点，但采用 EC 2+1 方案。
块A和B被分为两块，各2MB（因为2+1是两块），即A1+A2和B1+B2。 与副本不同，A1 不是 A2 的副本，它是一个虚拟块 A，分为两部分，与块 B 相同。总共，我们得到两组 4MB，每组包含两个 2MB 的块。 接下来，对于每个集合，以不超过 2 块（即 4 MB）的体积计算奇偶校验，我们获得额外的 + 2 块奇偶校验（AP 和 BP）。 总共我们有 2×2 数据 + XNUMX×XNUMX 奇偶校验。
接下来，这些片段被“布局”在节点之间，以便数据不会与其奇偶校验相交。 那些。 A1和A2不会与AP在同一节点上。
当其中一个节点（例如第三个）出现故障时，掉落的区块 B1 会自动从存储在 2 号节点上的 BP 奇偶校验中恢复，并在有故障的节点上被激活。没有 B 奇偶校验，即BP 的一部分。 在本例中，这是节点 1
相信读者一定有一个疑问：
“你所描述的一切早已被竞争对手和开源解决方案所实现，那么你在 ARDFS 中实施 EC 有何区别？”
然后 ARDFS 将会有一些有趣的功能。
注重灵活性的纠删码
最初，我们提供了一个相当灵活的 EC X+Y 方案，其中 X 等于 2 到 8 之间的数字，Y 等于 1 到 8 之间的数字，但总是小于或等于 X。该方案提供为了灵活性。 增加虚拟块被划分成的数据片(X)的数量允许减少开销成本，即增加可用空间。
增加奇偶校验块 (Y) 的数量可提高虚拟磁盘的可靠性。 Y 值越大，集群中可能发生故障的节点就越多。 当然，增加奇偶校验容量会减少可用容量，但这是为可靠性付出的代价。
性能对EC电路的依赖性几乎是直接的：“块”越多，性能越低；当然，这里需要一个平衡的观点。
这种方法允许管理员以最大的灵活性配置延伸存储。 在 ARDFS 池中，您可以使用任何容错方案及其组合，我们认为这也非常有用。
下表比较了几种（并非所有可能的）RF 和 EC 方案。
该表显示，即使是最“特里”的组合 EC 8+7（允许同时丢失集群中最多 7 个节点），也比标准复制“吃掉”更少的可用空间（1,875 比 2），并且保护效果好 7 倍，这使得这种保护机制虽然更复杂，但在需要在有限的磁盘空间条件下确保最大可靠性的情况下更具吸引力。 同时，您需要了解 X 或 Y 的每一个“加”都会带来额外的性能开销，因此在可靠性、节省和性能之间的三角关系中，您需要非常谨慎地选择。 因此，我们将专门撰写一篇文章来讨论纠删码大小调整。
文件系统的可靠性和自治性
ARDFS 在集群的所有节点上本地运行，并通过专用以太网接口使用自己的方式同步它们。 重要的一点是ARDFS不仅独立同步数据，还独立同步与存储相关的元数据。 在开发 ARDFS 时，我们同时研究了许多现有的解决方案，我们发现许多解决方案使用外部分布式 DBMS 来同步文件系统元数据，我们也使用它来进行同步，但只是配置，而不是 FS 元数据（关于此子系统和其他相关子系统）在下一篇文章中）。
使用外部 DBMS 同步 FS 元数据当然是一个可行的解决方案，但是 ARDFS 上存储的数据的一致性将取决于外部 DBMS 及其行为（坦率地说，这是一个任性的女士），这在我们的意见很糟糕。 为什么？ 如果FS元数据被损坏，FS数据本身也可以说“再见”，所以我们决定采取更复杂但更可靠的路径。
我们自己为 ARDFS 制作了元数据同步子系统，它完全独立于相邻子系统。 那些。 没有其他子系统可以损坏 ARDFS 数据。 我们认为，这是最可靠、最正确的方式，但时间会证明事实是否如此。 此外，这种方法还有一个额外的优点。 ARDFS 可以独立于 vAIR 使用，就像延伸存储一样，我们肯定会在未来的产品中使用它。
因此，通过开发 ARDFS，我们获得了一个灵活可靠的文件系统，您可以选择节省容量或放弃一切性能，或者以合理的成本实现超可靠的存储，但降低性能要求。
再加上简单的许可策略和灵活的交付模式（展望未来，vAIR 按节点许可，并作为软件或软件包交付），这使您能够非常精确地根据各种客户需求定制解决方案，并然后轻松维持这种平衡。
谁需要这个奇迹？
一方面，我们可以说，市场上已经有一些参与者在超融合领域拥有认真的解决方案，而这正是我们实际前进的方向。 看来这个说法是正确的，但是……
另一方面，当我们深入到现场与客户沟通时，我们和我们的合作伙伴发现事实并非如此。 超融合有很多任务，在一些地方，人们根本不知道这种解决方案的存在，在另一些地方，它似乎很昂贵，在另一些地方，替代解决方案的测试不成功，在另一些地方，由于制裁，他们根本禁止购买。 总的来说，这块田地没有耕过，所以我们去种植处女地）））。
存储系统什么时候比GKS更好？
当我们与市场合作时，经常被问到什么时候使用经典存储系统方案更好，什么时候使用超融合？ 许多生产 GCS 的公司（尤其是那些在其产品组合中没有存储系统的公司）表示：“存储系统正在变得过时，只有超融合！” 这是一个大胆的说法，但并不完全反映现实。
事实上，存储市场确实正在朝着超融合和类似的解决方案发展，但总有一个“但是”。
首先，按照存储系统的经典方案构建的数据中心和IT基础设施无法轻易重建，因此此类基础设施的现代化和完成仍然需要5-7年的时间。
其次，目前正在建设的基础设施大部分（指俄罗斯联邦）是根据使用存储系统的经典方案构建的，并不是因为人们不了解超融合，而是因为超融合市场是新的，解决方案和标准尚未建立，IT人员尚未接受培训，他们经验很少，但他们需要在此时此地建立数据中心。 而且这种趋势还将持续 3-5 年（然后是另一个遗产，见第 1 点）。
第三，纯粹的技术限制是每次写入 2 毫秒的额外小延迟（当然不包括本地缓存），这是分布式存储的成本。
好吧，我们不要忘记使用喜欢垂直扩展磁盘子系统的大型物理服务器。
在许多必要且流行的任务中，存储系统的表现比 GCS 更好。 当然，那些产品组合中没有存储系统的制造商不会同意我们的观点，但我们准备合理地争论。 当然，作为这两种产品的开发者，我们肯定会在未来的出版物中对存储系统和GCS进行比较，我们将清楚地展示在什么条件下哪个更好。
超融合解决方案在哪些方面比存储系统效果更好？
综合以上几点，可以得出三个明显的结论：
- 如果额外的 2 毫秒记录延迟并不重要，这种情况在任何产品中都会出现（现在我们不是在谈论合成产品，合成产品上可以显示纳秒），但超融合是合适的。
- 当大型物理服务器的负载可以转换为许多小型虚拟服务器并分布在节点之间时，超融合也将在那里发挥作用。
- 当水平缩放比垂直缩放优先级更高时，GCS 也能做得很好。
这些解决方案是什么？
- 所有标准基础设施服务（目录服务、邮件、EDMS、文件服务器、中小型 ERP 和 BI 系统等）。 我们称之为“通用计算”。
- 云提供商的基础设施，需要快速、标准化地水平扩展，并轻松地为客户“切割”大量虚拟机。
- 虚拟桌面基础设施 (VDI)，许多小型用户虚拟机在统一的集群中运行并安静地“浮动”。
- 分支机构网络，其中每个分支机构都需要一个由 15-20 个虚拟机组成的标准、容错且廉价的基础设施。
- 任何分布式计算（例如大数据服务）。 负载不是“深度”，而是“广度”。
- 可接受额外小延迟的测试环境，但存在预算限制，因为这些是测试。
目前，我们正是为了这些任务而制作了 AERODISK vAIR，并且我们正在重点关注这些任务（到目前为止是成功的）。 也许这种情况很快就会改变，因为…… 世界并非静止不动。
所以...
一系列文章的第一部分到此结束；在下一篇文章中，我们将讨论该解决方案的体系结构和所使用的组件。
我们欢迎提出问题、建议和建设性争议。
来源： habr.com