OpenStack Swift的深层世界:第1部分

这是我在多部深度探索系列的第一篇博客文章,它将探索我最喜欢的OpenStack的一个组件——Swift。我的主要目标是把我多年的经验放在这些帖子里。如果您知道您想要的是什么,Swift会有很好的记录,但是如果您处于亏损状态,这个系列将会对您有所帮助!

OpenStack Swift的深层世界

OpenStack Swift的深层世界

高度概括的观点

Swift是OpenStack的开源对象存储组件,它可以与其他OpenStack项目一起使用,比如Nova或作为一个独立产品。它使用像python和Rsync这样的开源程序来执行日常任务,扫描文件以进行损坏,并在节点停机时间或驱动器失败时把文件转移到安全的地方。

Swift代理有一些基本的部分:帐号/容器和对象。您可以将帐户/容器/对象组合在一个节点上(共享相同的存储),也可以在不同的节点上分解他们,以提高速度和数据的持久性。打破服务是明智的。它增加了容错功能,并且允许在不中断或降低服务的情况下发生更多的故障。

Swift的数据放置是由三个环文件帐户/容器和对象服务完成的。这些环包含了帐户/容器/对象节点的IPs,这是用于存储和分区信息的驱动器,而且这些信息由节点负责。您可能会问,环是什么?从环上的权威来源来看,这个环指的是在每个Swift节点(存储和代理节点)之间共享的三个文件:

实际上每一种类型的数据都是Swift处理的:对象、容器和账户。这些文件决定了哪些物理设备(硬盘)每个对象将被存储(还有每个容器和帐户)。

对象存储的设备数量依赖于为Swift集群指定的副本(复制)数量。您可以在环被创建或者稍后创建的时候配置您希望在集群中保存的副本数量,或者通过存储策略来实现。但是,存储策略不会影响帐户和容器副本。当您扩展您的Swift集群时,环就会自动地将集群上现有的数据移动到新的设备上,您只需将它们添加到环中,并随着时间的推移调整权值。

关于Swift的事实,我希望我在开始的时候就知道

任何客户都希望您能最大化每秒的交易量——毕竟,没有人会谈论跑车是如何建造的,它能从0到100英里每小时的速度有多快。Swift没有什么不同,它完全是关于客户端速度和使交易尽最大可能流动得更快。

在写/上传后,代理层数学返回200 OK,如下:

客户开始上传。

如果任何的初选失败连接到交接节点,代理会打开连接到所有的主节点上

当满足以下条件时,会返回一个201,副本/2+1=201被创建。

来看一个有3个副本的例子:

客户端将文件写入到容器中

除非3/2+1=2被写入磁盘,否则客户端将不会返回一个201

您可以放心地假设两个副本被刷新到稳定的存储空间,“第三个”副本将被复制传递所填充。在正常操作中,所有三个副本都会被存储并同步到磁盘。如果只有两个被写入,这个丢失的副本将被一个背景复制后台程序填充。如果只写入一个(或0),则给出一个5XX类型的响应,客户端将不得不重试。

这些假设应该是您如何构建集群布局的基础。当代理服务器遇到写入到主位置的错误时,将选择一个切换节点。当这种情况发生时,我们将依赖复制以在主服务器再次可用时,将数据传送到正确的主服务器。有很多原因会导致一个主服务器离线,包括停机事件、网络问题或者驱动太忙而无法接受当前的请求。在随后的GET/HEAD到对象时,对象必须只出现在一个主服务器(或一个切换)上,以获得成功的响应。

数据放置在Swift

Swift是独特的,因为数据放置是以这些固定的原则操作的,范围-》 区域 -》磁盘 。由于在本例中失败域是磁盘,所以我们绕过了“节点”。由于多区域超出了本文的范围,让我们集中在区域上。对于某些人来说,区域可能是一个非常混乱的概念。一个区域是抽象的,它可以是一个数据中心,一个数据库,一个电源,一个架子——这个列表还可以有更多。让我们来探索一下如何处理分区生产工作负载——对于数据中心管理员和运行基础设施的工程师来说,意图是合理的。

到目前为止,这是我的逻辑,

假设您有一个物体A。

您可以将它写入Swift集群、三个副本、三个柜子和三个区域。代理将编写副本/2+1,因此将两个副本写到磁盘上以解释失败的原因。

如果所有节点都启动并运行,那么您现在知道在两个柜子中有两个副本。第三个副本将由复制填充。

这个逻辑很好对吧?

我们假设它是第三个移位,一个TOR(架子上的顶部)开关在一个柜子上。如果您采用我刚才提到的分区规划,您就会知道您有百分之百的准确性,您有两个副本仍然生活在另外两个柜子里,所以不要惊慌失措。假设您失去了三个结点,在三个区域z0 z1 z2。是的,您知道环上有“失踪”或“不可用”的数据——这时可以点击“panic”按钮!

在这个内阁分区中做任何服务器工作都很简单。在Rackspace,我们通常会有一个大规模的部署,有多个柜子。当需要在硬件上进行一些重新工作时,我对DC人员的指示是一次在一个柜子上执行工作。这允许百分之百的确定多个副本仍然存在,并且节点在旋转中循环使用时客户没有经历数据丢失或不可用的对象。

另一个有趣的技巧是:为了减少TOR切换到TOR的交换机流量,您应该在同一个柜子中安装代理服务器,与帐户/容器/对象服务器相同,并使用每个内阁的阅读关联和范围。这将减少内阁的交叉讨论,并为大多数工作负载带来更快的性能。

硬件方面的考虑

重要的是要理解Swift利益是来自不同硬件配置对不同集群的需求:

代理服务器将会在CPU和网络上进行大量的工作,因为有一个对象出现,并且多个副本被同步地写到后端对象存储。根据环的大小,您可能需要在代理层增加内存。

帐户/容器/对象服务器需要原始磁盘速度,帐户/容器将从SSD或NVME介质中受益,因为帐户/容器服务是sqlite数据库,有时需要很高的吞吐量。突袭帐户/容器SSD可以实现更高的IO,并且应该在需要它的高性能边缘应用中使用。除了使用RAID操作系统驱动的持久性外,这是在Swift环境中进行硬件RAID的唯一适合的地方。

对象服务器应该配置HBAs或RAID卡,使用直通对象存储。XFS最佳实践还规定,任何hHBA/RAID缓存都被禁用,如果在缓存中存在故障,启用高速缓存可能会导致损坏。

软件和网络方面的考虑

正如您所期望的那样,为Swift优化网络也是一个挑战。我们发现的一些最佳实践包括:

账户/容器/对象/代理服务器将受益于独立分离的网络,一个用于管理/传入写道,另一个用于复制网络。我们在这两个网络上使用LACP L3+4的连接获得了巨大的性能提升,用来提高吞吐量和网络弹性。

如果您正在为特定的工作负载类型设置Swift,那么为不同的XFS选项运行bonnie++,比如agcount和logbsize,可以从磁盘中挤出额外的性能。与往常一样,试着在合成的标杆管理之后测试特定的工作负载,以确保结果像预期的那样。

Sysctl可协调的应集中在关于TCP连接,如果您运行nf_conntrack,违约则需要提高,我建议以500 k /账户/容器/对象/代理作为起点并且进行适当地监控如果您开始生产了这些限定产品。

TCP重用应该能够减少在正常生产过程中发生的TCP巨大的开销。

磁盘上的故障

就拿缺点来说,Swift和它的功能并没有什么魔力。

Swift使用像rsync这样的开源二进制文件来移动数据。如果您有一个损坏的驱动器,那么数据将不会被重新构建,直到该驱动器被替换或从环中删除。

这是关键,因为其他对象存储将重新构建失败的副本,直到该驱动器再次可用或从环中删除。

如果一个有故障的设备或服务器从环上被移除,一个新的或已经存在的驱动器将会在重新平衡发生后将这些分区转移到它上面。在一个集群中有多个驱动器会失效,随着时间的推移,您会增加在这些驱动器上共享公共数据的可能性,直到您尝试重新读取这些数据,您才会知道它可能会永远消失。

结论

我希望您喜欢我们关于Swift数据放置的概述,以及如何最好地设计您的内部Swift集群,从内阁设计到服务放置。如果您按照这些准则来设置您的集群,并且在您的脑海中一年又一年地增强,那么在未来的几年里,除了定期更换错误的驱动器之外,Swift将会毫无瑕疵地运行。

在即将发布的文章中,我将介绍可以从您的Swift集群中提取的日常遥测技术,以及如何阅读和应对您可能在日常的集群操作中遇到的不同情况。我还将阐明硬盘/阅读失败的情况,对Swift进行审计以保持其真实性,还有如何最好地处理无记载数据损坏和怎样保持数据的安全。

此内容是由lunarpages主机中文导航提供,如果您想转载此内容,请注明出处:http://lunarpages.cn/

Add Comment

Required fields are marked *. Your email address will not be published.