哈Ha！

在现代应用程序的工作中涉及大量数据，并且其流量在不断增长，这已经不是什么秘密了。通常需要从大量计算机中存储和处理此数据，这并非易事。为了解决这个问题，有云对象存储。通常，它们是软件定义存储技术的实现。

在2018年初，我们推出了（并推出了！）我们自己的基于Cloudian HyperStore的100％兼容S3的存储。事实证明，该网络很少有关于Cloudian本身的俄文出版物，甚至很少有关于该解决方案的实际应用的出版物。

今天，基于DataLine的经验，我将向您介绍Cloudian软件的体系结构和内部结构，包括基于许多Apache Cassandra体系结构解决方案的Cloudian SDS实现。另外，我们认为在SDS存储中最有趣的是确保容错和对象分布的逻辑。

如果您正在构建S3存储或正忙于维护它，那么本文将对您很方便。

首先，我将解释为什么我们的选择落在Cloudian上。很简单：在这个利基市场中，很少有有价值的选择。例如，几年前，当我们只是考虑建筑时，只有三种选择：

CEHP + RADOS网关；
小野
Cloudian HyperStore。

对于我们来说，作为服务提供商，决定性因素是：存储API与原始Amazon S3之间的高度对应关系，内置计费的可用性，具有多区域性支持的可伸缩性以及供应商支持的第三线。 Cloudian拥有所有这些。

是的，最（肯定是！）最重要的是，DataLine和Cloudian具有相似的公司颜色。您必须承认我们无法抗拒这种美丽。

不幸的是，Cloudian并不是最常见的软件，而且RuNet中几乎没有关于它的信息。今天，我们将纠正这种不公正现象，并与您讨论HyperStore架构的功能，检查其最重要的组件并处理主要的架构细微差别。让我们从最基本的开始，即-Cloudian到底是什么？

Cloudian HyperStore存储如何工作

让我们看一下图，看看Cloudian解决方案是如何工作的。

主要组件存储方案。

如我们所见，该系统由几个主要组件组成：

Cloudian管理控制 - 管理控制台 ;
管理员服务 - 内部管理模块 ;
S3服务 - 负责支持S3协议的模块；
HyperStore Service- 实际的存储服务 ；
Apache Cassandra- 服务数据的集中存储库 ；
Redis- 用于最频繁读取的数据 。

我们最感兴趣的是主要服务S3 Service和HyperStore Service的工作，然后我们将仔细考虑它们的工作。但是首先，找出集群中服务的分配方式以及该解决方案作为一个整体的数据存储的容错性和可靠性是有意义的。

上图中的通用服务是指服务S3，HyperStore，CMC和Apache Cassandra 。乍一看，一切都是美丽而整洁的。但是，仔细检查后发现，只有一个节点故障才能有效解决。同时一次丢失两个节点对于群集可用性可能是致命的-Redis QoS（在节点2上）只有1个从节点（在节点3上）。具有失去群集管理风险的相同情况-Puppet Server仅在两个节点（1和2）上。但是，两个节点一次发生故障的可能性非常低，您可以忍受它。

但是，为了提高存储的可靠性，我们在DataLine中使用4个节点，而不是最少3个。获得以下资源分配：

另一个细微差别立即引起您的注意-Redis凭据并不是放在每个节点上（可以从上面的官方方案中假定），而只是放在其中的三个节点上。在这种情况下， Redis凭据用于每个传入请求。事实证明，由于需要使用其他人的Redis，第四个节点的性能有些不平衡。

对于我们来说，这还不重要。在压力测试过程中，没有注意到节点响应速度的明显偏差，但是在数十个工作节点的大型群集上，纠正此细微差别是有意义的。

这是6个节点上的迁移方案的样子：

该图显示了在发生节点故障时如何实现服务迁移。 仅考虑每个角色的一台服务器的故障。 如果两个服务器均掉落，则需要手动干预。

在这里，业务也不是没有一些微妙之处。角色迁移使用Puppet。因此，如果丢失或不小心破坏了它，则自动故障转移可能无法正常工作。出于同样的原因，您不应该手动编辑内置Puppet的清单。这不是完全安全的，因为清单是使用集群管理面板编辑的，所以更改可能会突然磨损。

从数据安全性的角度来看，一切都更加有趣。对象元数据存储在Apache Cassandra中，每条记录复制到4个节点中的3个。复制因子3也用于存储数据，但是您可以配置更大的一个。即使在4个节点中有2个同时发生故障的情况下，这也可以确保数据安全。而且，如果您有时间重新平衡群集，则剩下的一个节点将不会造成任何损失。最主要的是要有足够的空间。

这是两个节点发生故障时发生的情况。 该图清楚地表明，即使在这种情况下，数据仍然安全

同时，数据和存储的可用性将取决于确保一致性的策略。对于数据，元数据，读取和写入，它是单独配置的。

有效选项是至少一个节点，仲裁或所有节点。
此设置确定为了确认请求成功，必须确认多少个节点进行写/读。我们将仲裁作为在处理请求所需的时间与写入的可靠性/读取的一致性之间的合理折衷。也就是说，从操作中涉及的三个节点中，对于无错误操作，足以从2中获得一致的答案。因此，为了在多个节点发生故障的情况下保持稳定，您将需要切换到单个写入/读取策略。

Cloudian中的查询处理

下面，我们将考虑在Cloudian HyperStore中处理传入请求的两种方案：PUT和GET。这是S3服务和HyperStore的主要任务。

让我们从如何处理写请求开始：

当然，您注意到每个请求都会生成大量检查和数据检索，每个组件之间至少有6个匹配项。从这里开始，处理小文件时会出现记录延迟和高CPU时间消耗。

大文件按块传输。单独的块不视为单独的请求，并且不会执行某些检查。

接收到初始请求的节点还可以独立确定写入位置和内容，即使该请求没有直接写入该位置。这使您可以从最终客户端隐藏群集的内部组织，并使用外部负载平衡器。所有这些都会积极影响存储的维护简便性和容错能力。

如您所见，读取逻辑与写入没有太大不同。在其中，观察到对处理对象的尺寸具有同样高的性能敏感性。因此，由于在处理元数据方面节省了大量资金，因此提取一个切碎的对象要比许多相同总量的单独对象容易得多。

数据存储和复制

从上图可以看到，Cloudian支持各种数据存储和复制方案：

复制 -使用复制，可以在系统中维护每个数据对象的自定义数量的副本，并将每个副本存储在不同的节点上。例如，使用3X复制，将创建每个对象的3个副本，并且每个副本“位于”其自己的节点上。

擦除编码 -使用擦除编码，将每个对象编码为自定义数量（称为K数）的数据片段加上自定义数量的冗余码（M数）。一个对象的每个K + M个片段都是唯一的，并且每个片段都存储在其自己的节点上。可以使用任何K个片段对对象进行解码。换句话说，即使无法访问M个节点，对象仍然可读。

例如，在纠删编码中，根据4 + 2公式（4个数据片段加上2个冗余代码片段），每个对象被分成存储在六个不同节点上的6个唯一片段，并且如果6个片段中有4个可用，则可以还原和读取该对象。

与复制相比，擦除编码的优点是节省空间，尽管以显着增加处理器负载，降低响应速度和需要后台过程控制对象一致性为代价。无论如何，元数据都与数据分开存储（在Apache Cassandra中），这增加了解决方案的灵活性和可靠性。

简要介绍HyperStore的其他功能

正如我在本文开头所写，HyperStore内置了一些有用的工具。其中包括：

灵活的计费，支持根据数量和资费计划更改资源价格；
内置监控
限制用户和用户组使用资源的能力；
QoS设置和用于平衡节点之间资源使用的内置过程，以及用于在节点与节点上的磁盘之间进行平衡或在群集中输入新节点时进行常规平衡的常规过程。

但是，Cloudian HyperStore仍不完美。例如，由于某种原因，您不能将现有帐户转移到另一个组或将多个组分配给一个记录。无法生成临时账单报告-您只有在报告期结束后才能收到所有报告。因此，无论是客户还是我们都无法实时了解到该帐户的增长额。

Cloudian HyperStore逻辑

现在，我们将更深入地研究SDS存储中最有趣的部分-按节点分配对象的逻辑。对于Cloudian存储，元数据与数据本身分开存储。对于元数据，Cassandra用于专有HyperStore解决方案作为数据。

不幸的是，到目前为止，Internet上还没有将Cloudian文档正式翻译成俄文，因此下面我将发布本文档中最有趣的部分的翻译。

Apache Cassandra在HyperStore中的作用

在HyperStore中，Cassandra用于存储对象元数据，用户帐户信息和服务使用情况数据。在每个HyperStore上的典型部署中，Cassandra数据与OS存储在同一驱动器上。该系统还在每个节点上的专用驱动器上支持Cassandra数据。 Cassandra数据未存储在HyperStore数据磁盘上。将vNode分配给主机后，它们只会分配给HyperStore存储节点。 vNode未分配给存储Cassandra数据的驱动器。
在集群内部，根据存储库的策略（策略）复制Cassandra中的元数据。 Cassandra数据复制通过以下方式使用vNode：

创建新的Cassandra对象（主键及其对应的值）时，将对其进行哈希处理，并且使用哈希将对象与特定vNode关联。系统检查此vNode分配给哪个主机，然后将Cassandra对象的第一个副本存储在该主机上的Cassandra驱动器上。
例如，假设为主机分配了分布在多个HyperStore数据磁盘上的96个vNode。哈希值落在这96个vNode的任何令牌范围内的Cassandra对象将被写入此主机上的Cassandra驱动器。
Cassandra对象的其他副本（副本的数量取决于您的配置）与具有以下序列号的vNode关联，并存储在分配给这些vNode的节点上，前提是必要时“跳过” vNode，以便将Cassandra对象的每个副本存储在另一个节点上主机。

HyperStore存储如何工作

S3对象在HyperStore群集中的放置和复制基于一致的缓存方案，该方案使用范围为0到2 ¹²⁷ -1的整数令牌空间。整数令牌已分配给HyperStore节点。对于每个S3对象，在将哈希加载到存储中时都会计算哈希值。对象存储在分配了令牌最低值的节点中，该值大于或等于对象的哈希值。通过将对象存储在已分配令牌的节点上，该令牌具有最小值，也可以实现复制。

在“经典”的基于哈希的一致存储中，一个令牌被分配给一个物理节点。 Cloudian HyperStore系统使用并扩展了版本1.2的Cassandra中引入的“虚拟节点”（vNode）的功能-大量令牌分配给每个物理主机（最多256个）。实际上，存储群集由大量“虚拟节点”组成，每个物理主机上都有大量虚拟节点（令牌）。

HyperStore系统为每个物理主机上的每个磁盘分配一组单独的令牌（虚拟节点）。主机上的每个磁盘都负责其自己的对象副本集。磁盘故障仅影响其上对象的副本。主机上的其他驱动器将继续运行并履行其数据存储职责。

我们给出一个示例，并考虑一个由6个HyperStore主机组成的群集，每个主机具有4个S3存储磁盘。假设为每个物理主机分配了32个令牌，并且令牌空间从0简化到960，并且该系统中192个令牌的值（6个主机的32个令牌）的值为0、5、10、15、20，依此类推，直到955。

下图显示了整个集群中令牌的一种可能分布。每个主机的32个令牌平均分布在4个磁盘上（每个磁盘8个令牌），令牌本身随机分布在整个群集中。

现在，假设您将HyperStore配置为3X复制S3对象。让我们同意将S3对象加载到系统中，并将应用于其名称的哈希算法提供给我们322哈希值（在此简化的哈希空间中）。下图显示了对象的三个实例或副本将如何存储在集群中：

使用其哈希值名称322，该对象的第一个副本存储在325令牌上，因为这是大于或等于对象的哈希值的最小令牌值。 325个令牌（在图中以红色突出显示）已分配给hyperstore2：Disk2。因此，对象的第一副本存储在此处。

第二个副本存储在分配了下一个令牌（330，橙色突出显示）的磁盘上，即在hyperstore4：Disk2上。
第三个副本保存到磁盘，在hyperstore3上为磁盘分配了下一个令牌，该令牌在330-335（黄色）之后（黄色）。

我将添加一条评论：从实际的角度来看，不仅需要这种优化（不仅在物理节点之间，而且在各个磁盘之间分配令牌），不仅要确保可访问性，而且还需要确保磁盘之间数据的均匀分配。在这种情况下，不使用RAID阵列，磁盘上数据分配的整个逻辑由HyperStore本身控制。一方面，它很方便且受控制；如果磁盘丢失，则所有内容将自行重新平衡。另一方面，我个人相信更多优秀的RAID控制器-毕竟，它们的逻辑已经优化了很多年。但是，这些都是我个人的喜好，在真正的障碍和问题上，如果我们在物理服务器上安装软件时遵循供应商的建议，那么我们永远也不会遇到HyperStore。但是，在存储系统的同一个月球上使用虚拟化和虚拟磁盘的尝试失败了，当在负载测试期间使存储系统超载时，HyperStore变得疯狂，并且数据完全不均匀地散布，从而阻塞了某些磁盘而没有接触其他磁盘。

驱动集群内的设备

回想一下，每个主机有32个令牌，并且每个主机的令牌在其磁盘之间均匀分布。让我们仔细看一下hyperstore2：Disk2（在下图中）。我们看到令牌325、425、370等已分配给该磁盘。

由于集群配置用于3X复制，因此以下内容将存储在hyperstore2上：Disk2：

按照325磁盘令牌：

哈希值从320（不含）到325（含）的对象的第一个副本；
哈希值从315（专有）到320（包括）的对象的第二个副本；
哈希值从310（专有）到315（包括）的对象的第三副本。

根据425磁盘令牌：

哈希值从420（不含）到425（含）的对象的第一个副本；
哈希值从415（专有）到420（包括）的对象的第二个副本；
哈希值从410（专有）到415（包括）的对象的第三副本。

依此类推。

如前所述，在放置第二个和第三个副本时，HyperStore在某些情况下可能会传递令牌，以便在一个物理节点上不存储对象的一个以上副本。这消除了使用hyperstore2：disk2作为同一对象的第二个或第三个副本的存储的情况。

如果磁盘2在磁盘1、3和4上崩溃，则数据将继续存储，并且磁盘2上的对象将存储在群集中，因为已复制到其他主机。

: , / HyperStore Cassandra. , , , , «» . . . , : , , .

现在，让我们看一下HyperStore在多个数据中心和区域中的工作方式。在我们的情况下，多DPC模式通过使用一个或多个令牌空间而不同于多区域模式。在第一种情况下，令牌空间是统一的。在第二个区域中，每个区域将具有一个独立的令牌空间，该令牌空间具有（可能）具有自己的一致性，容量和存储配置级别的设置。
要了解它是如何工作的，让我们再次转到文档翻译的“多数据中心部署”部分。

考虑在两个数据中心中部署HyperStore。称它们为DC1和DC2。每个数据中心都有3个物理节点。与前面的示例一样，每个物理节点都有四个磁盘，每个主机分配了32个令牌（vNode），我们假设简化的令牌空间为0到960。根据具有多个数据中心的这种情况，令牌空间分为192个令牌- 6个物理主机中的每一个32个令牌。令牌是由主机绝对随机分配的。

还假设在这种情况下，S3对象的复制在每个数据中心的两个副本上进行配置。

让我们看一下假设的H3值为942的S3对象如何在2个数据中心中复制：

vNode 945 ( ), DC2, hyperstore5:Disk3.
vNode 950 ( ) DC2, hyperstore6:Disk4.
vNode 955 DC2, , vNode .
vNode 0 () — DC1, hyperstore2:Disk3. , (955) (0).
vNode (5) DC2, , vNode .
vNode 10 () — DC1, hyperstore3:Disk3.

: , , , , . , .

Cloudian. , , . , , , , .
S3 DataLine, , !

S3 DataLine存储如何工作