开源软件名称:FastOSS
开源软件地址:https://gitee.com/xxjay/FastOSS
开源软件介绍:
FastOSS 分布式对象存储系统系统架构介绍采用中间控制节点架构,由中间服务器控制集群。 - Tracker:中间控制节点,负责管理对象的存储位置和存储桶权限等信息。
- Storage:存储节点,存储对象数据以及对象的元数据。
- Proxy:代理服务器,负责接收HTTP请求并转发到系统中对应的处理服务器。Proxy服务器是无状态的,可以通过Nginx做负载均衡。
- Zookeeper:使用Zookeeper来管理Storage服务器,解除Tracker和Storage的耦合,避免Tracker管理大量的Storage服务器连接和心跳。
Tracker服务Tracker记录了对象存储系统中每个对象的具体位置(在哪台Storage服务器上),同时它也作为存储桶访问权限的认证中心。 BitCask存储模型为了保证不丢失对象的位置信息,Tracker使用了BitCask模型来存储KV数据。BitCask的优势在于,它将数据的写操作(增删改)全部转化成了顺序写,相比于随机写大大提升了写入速度。 一致性Hash负载均衡在选择主副本存储位置时,Tracker服务器目前使用一致性Hash算法来保证Storage负载均衡。在后续的开发中将陆续引入轮询、加权轮询等更多的负载均衡算法。 存储桶访问权限对象存储不具有文件系统的目录层级结构,不过用户可以使用存储桶来集中管理对象。在FastOSS中,存储桶有三种访问权限设置: - 私有(Private):对存储桶的读写全部是私有操作。
- 公共读(Public_Read):存储桶开放读请求,写请求为私有。
- 公共写(Public_Write):存储桶完全开放读写请求。
每个存储桶在创建后会生成唯一的AppID、AccessKey和SecretKey。用户通过这三个字符串来访问存储桶。 对于私有请求,用户需要通过SDK的Token工具,根据AccessKey和SecretKey生成访问Token,并在请求中携带Token。 Tracker缺陷目前的Tracker是系统中唯一的单点,也就是整个系统最大的缺陷。为了避免单点的不可靠性,后续的更新会将Tracker集群化来达到高可用要求。 Storage服务Storage存储了对象的数据和元数据。 大量小文件存储优化由于系统的定位是存储大量小文件,所以Storage服务对小文件存储做了优化。 操作系统对每一个文件都会记录一份元数据,也就是Linux中的inode,其中包括权限组、用户组等信息。这些信息在对象存储中没有任何意义,但是会占据磁盘空间。在海量小文件的情境下,大量的文件系统元数据会占用大量磁盘资源。 为了解决该问题,FastOSS将小文件合并成大文件(Chunk),并规定每个大文件大小固定。单个的小文件都会已追加的形式写入大文件。通过这种方式减少额外的元数据存储,提升资源利用率。 删除文件时只需要在内存标记删除,后台会有专门的线程来压缩大文件中被删除的部分。 备份机制在FastOSS中对于一个写操作,都会尝试去向半数以上的节点写入,不过我们规定只要有一台主机成功收到了副本就算成功。剩下的副本是由成功接收的主机在后台完成同步的。 在读取时,Proxy会尝试根据Quorum机制从R个主机遍历读取,直到成功读取到最新数据。 Quorum定义如下:假设有N个副本,更新操作wi 在W个副本中更新成功之后,才认为此次更新操作wi 成功。称成功提交的更新操作对应的数据为:“成功提交的数据”。对于读操作而言,至少需要读R个副本才能读到此次更新的数据。**其中,W+R>N ,即W和R有重叠。**一般,W+R=N+1。 数据可靠性备份是最常见的数据可靠机制,FastOSS采用了最常用的三副本机制配合Quorum读写。不过副本机制并不能100%保证可靠,所以FastOSS在后续更新中会逐渐添加如EC码等更高级的机制。 EditLog编辑日志FastOSS中的元数据除了保存在内存中还会用编辑日志的方式写入硬盘,这种机制类似Redis的AOF持久化。 众所周知,磁盘的写入速度是远不如内存的,为了提高元数据刷盘的效率,FastOSS不会把每一条元数据立即写入磁盘,而是将元数据记录先写入内存的缓冲区,再按照刷盘规则写入磁盘。 Proxy服务Proxy类似存储系统的网关,它负责接收外部传来的Http请求,然后通过与系统内部的其他服务器交互请求完成处理,最终返回Http回复。 因为Proxy服务是无状态的,所以可以部署多台Proxy服务器并使用Nginx等工具做负载均衡。 对于热点数据,比如多次访问的Object的位置、多次访问的存储桶的权限,Proxy服务器会进行缓存,通过缓存来提高访问速度。 |
请发表评论