撰写本文的目的是帮助您选择适合自己的解决方案,并了解 Gluster、Ceph 和 Vstorage (Virtuozzo) 等 SDS 之间的差异。
文本使用了更详细地披露某些问题的文章链接,因此描述将尽可能简短,使用要点,没有不必要的废话和介绍性信息,如果您愿意,您可以在互联网上独立获取这些信息。
事实上,当然,提出的主题需要文本的语气,但在现代世界越来越多的人不喜欢阅读很多))),所以你可以快速阅读并做出选择,如果有什么不清楚,请点击链接或谷歌不清楚的话))),而这篇文章就像这些深层主题的透明包装,显示填充物 - 每个决定的主要关键点。
糊状
让我们从 Gluster 开始,它被超融合平台制造商积极使用,其基于开源的 SDS 适合虚拟环境,可以在 RedHat 网站的存储部分找到,您可以从两个 SDS 选项中进行选择:Gluster 或 Ceph。
Gluster 由一堆翻译器组成 - 执行分发文件等所有工作的服务。 Brick 是一项为一个磁盘提供服务的服务,Volume 是将这些 Brick 结合在一起的卷(池)。 接下来是使用 DHT(分布式哈希表)功能将文件分组的服务。 我们不会在描述中包含分片服务,因为下面的链接将描述与其相关的问题。
写入时,整个文件存储在brick中,并且其副本同时写入第二台服务器上的brick中。 接下来,第二个文件将被写入不同服务器上的第二组两个砖块(或更多)。
如果文件大小大致相同并且卷仅由一组组成,那么一切都很好,但在其他情况下,描述中会出现以下问题:
- 组中的空间利用不均匀,这取决于文件的大小,如果组中没有足够的空间来写入文件,您将收到错误,文件将不会被写入,也不会重新分配到另一个组;
- 写一个文件时,IO只去一组,其余的都是空闲的;
- 写一个文件时无法获取整个卷的IO;
- 由于缺乏将数据分布到块中,总体概念看起来效率较低,在块中更容易平衡和解决均匀分布的问题,而不是像现在整个文件进入块。
从官方描述来看
这些发现也与用户体验的描述有关
图为写入两个文件时的负载分布,其中第一个文件的副本分布在前三台服务器上,这三台服务器合并为卷 0 组,第二个文件的三个副本放置在三台服务器的第二组卷 1 上服务器。 每台服务器有一个磁盘。
一般的结论是,您可以使用 Gluster,但要了解性能和容错能力会受到限制,这会在超融合解决方案的某些条件下产生困难,其中虚拟环境的计算负载也需要资源。
还有一些Gluster的性能指标是在一定条件下可以达到的,仅限于
头孢
现在让我们从架构描述中了解 Ceph
建筑
从架构的描述来看,核心是CRUSH,通过它选择存储数据的位置。 接下来是 PG——这是最难理解的抽象(逻辑组)。 需要 PG 才能使 CRUSH 更加有效。 PG的主要目的是对对象进行分组,以减少资源消耗,提高性能和可扩展性。 直接单独寻址对象而不将它们组合到 PG 中将非常昂贵。 OSD 是针对每个单独磁盘的服务。
一个集群可以有一个或多个数据池,用于不同的目的和不同的设置。 池分为放置组。 置放群组存储客户端访问的对象。 这是逻辑级别结束、物理级别开始的地方,因为每个置放群组都分配有一个主磁盘和多个副本磁盘(具体数量取决于池复制因子)。 换句话说,在逻辑级别,对象存储在特定的置放群组中,在物理级别 - 存储在分配给它的磁盘上。 在这种情况下,磁盘可以物理上位于不同的节点,甚至位于不同的数据中心。
在这个方案中,归置组看起来像是整个解决方案灵活性的必要级别,但同时,作为这个链条中的一个额外环节,这不自觉地意味着生产力的损失。 例如,在写入数据时,系统需要将其拆分为这些组,然后在物理层面分为主盘和副本盘。 也就是说,哈希函数在搜索和插入对象时起作用,但有一个副作用 - 重建哈希的成本非常高并且受到限制(当添加或删除磁盘时)。 另一个哈希问题是无法更改的明确固定的数据位置。 也就是说,如果不知何故磁盘负载增加,那么系统没有机会不写入它(通过选择另一个磁盘),散列函数迫使数据根据规则定位,无论多么糟糕磁盘是这样的,所以Ceph在重建PG时会消耗大量内存,以防自我修复或增加存储。 结论是,Ceph 运行良好(尽管很慢),但前提是没有扩展、紧急情况或更新。
当然,可以选择通过缓存和缓存共享来提高性能,但这需要良好的硬件,并且仍然会有损失。 但总体而言,在生产力方面,Ceph 看起来比 Gluster 更有吸引力。 此外,在使用这些产品时,有必要考虑一个重要因素 - 这是高水平的能力、经验和专业精神,特别是 Linux,因为正确部署、配置和维护一切非常重要,这给管理者带来了更多的责任和负担。
存储空间
该架构看起来更有趣
存储可以与 kvm-qemu 管理程序的服务共存,这些只是已找到紧凑的最佳组件层次结构的几个服务:通过 FUSE 安装的客户端服务(已修改,非开源)、MDS 元数据服务(元数据服务),service Chunk服务数据块,物理层面相当于一块磁盘仅此而已。 当然,就速度而言,最好使用具有两个副本的容错方案,但如果您在 SSD 驱动器上使用缓存和日志,则可以在 SSD 驱动器上对容错编码(擦除编码或 raid6)进行适当的超频。混合方案,甚至在全闪存上更好。 EC(擦除编码)有一些缺点:当改变一个数据块时,需要重新计算奇偶校验量。 为了避免与此操作相关的损失,Ceph 延迟写入 EC,并且在某个请求期间可能会出现性能问题,例如,当需要读取所有块时,在 Virtuozzo Storage 的情况下,会执行写入更改的块使用“日志结构文件系统”方法,最大限度地减少奇偶校验计算成本。 为了大致估计有和没有 EC 的加速工作的选项,有
存储组件的简单图并不意味着这些组件不吸收
有一个方案可以比较Ceph和Virtuozzo存储服务对硬件资源的消耗。
如果以前可以使用旧文章、使用其中最重要的行来比较 Gluster 和 Ceph,那么使用 Virtuozzo 就更困难了。 关于该产品的文章并不多,信息只能从以下文档中收集
我会尝试帮助描述这个架构,所以文字会多一点,但是自己理解文档需要花很多时间,而且现有的文档只能通过修改表格来作为参考内容或按关键字搜索。
让我们考虑一下具有上述组件的混合硬件配置中的记录过程:记录开始转到客户端启动它的节点(FUSE 安装点服务),但元数据服务 (MDS) 主组件当然会转到将客户端直接定向到所需的 chunk 服务(存储服务 CS 块),即 MDS 不参与记录过程,而只是将服务定向到所需的 chunk。 总的来说,我们可以用往桶里倒水来录音来比喻。 每个桶是一个 256MB 的数据块。
即一个磁盘就是一定数量的这样的桶,即磁盘体积除以256MB。 每个副本分布到一个节点,第二个副本几乎并行到另一个节点,等等...如果我们有三个副本,并且有 SSD 磁盘用于缓存(用于读取和写入日志),那么写入后将发生写入确认将日志写入 SSD,并且 SSD 的并行重置将在 HDD 上继续,就像在后台一样。 如果有三个副本,则在第三个节点的 SSD 确认后才会提交记录。 看起来三个 SSD 的写入速度之和除以 XNUMX 就可以得到一个副本的写入速度,但副本是并行写入的,网络延迟速度通常比 SSD 更高,事实上,写入性能将取决于网络。 在这方面,为了看到真实的IOPS,您需要通过以下方式正确加载整个Vstorage
上述SSD上的记录日志的工作原理是,只要数据进入其中,服务立即读取该日志并写入HDD。 每个集群有多个元数据服务 (MDS),它们的数量由法定人数决定,法定人数根据 Paxos 算法工作。 从客户端的角度来看,FUSE挂载点是一个集群存储文件夹,对集群中的所有节点同时可见,每个节点根据这个原理都有一个挂载的客户端,因此这个存储对于每个节点都是可用的。
对于任何上述方法的性能,在规划和部署阶段,正确配置网络非常重要,其中由于聚合和正确选择的网络通道带宽而存在平衡。 在聚合中,选择正确的哈希模式和帧大小非常重要。 与上述 SDS 也有很大的区别,这是与 Virtuozzo Storage 中的快速路径技术的融合。 与其他开源解决方案不同,除了现代化的保险丝之外,它还显着提高了 IOPS,并使您不受水平或垂直扩展的限制。 总的来说,与上面描述的架构相比,这个看起来更强大,但是为了这种乐趣,当然需要购买许可证,这与 Ceph 和 Gluster 不同。
总而言之,我们可以强调三者中的佼佼者:Virtuozzo Storage 在架构的性能和可靠性方面排名第一,Ceph 排名第二,Gluster 排名第三。
选择 Virtuozzo Storage 的标准:它是一组最佳的架构组件,针对这种 Fuse 方法进行了现代化改造,具有快速路径、一组灵活的硬件配置、更少的资源消耗以及与计算共享的能力(计算/虚拟化),也就是说,它完全适合超融合解决方案,而他就是其中的一部分。 第二名是 Ceph,因为与 Gluster 相比,它是一种更高效的架构,因为它在块中运行,并且具有更灵活的场景和在更大集群中工作的能力。
计划写一篇 vSAN、Space Direct Storage、Vstorage 和 Nutanix Storage 的比较,在 HPE 和华为设备上测试 Vstorage,以及 Vstorage 与外部硬件存储系统集成的场景,所以如果你喜欢这篇文章,那就很高兴收到您的反馈,考虑到您的评论和愿望,这可以增加新文章的动力。
来源: habr.com