AmazonS3架构分析

1、Amazon S3存储系统结构Eucalyptus是Amazon AWS勺开源实现，总体的架构跟实现都是根据AmazonAWS来设计的，所以Eucalyptus的存储系统部分也不例外，下面是 AamzonS3存 储系统实现的架构。一、存储形式S3是基于桶（Bucket）的存储系统，它把每个被存储的文件当做一个Object,被存储的Object被放到相应的Bucket中，如下所示：1） Bucket用户创建的Bucket的BucketName必须是全局唯一的，该名字可以由用户提供，也可以由系统提供。创建的同时会设置Bucket的一些属性：MetaData：包含创建时间、创建者标识、该Bucket

2、中所有Objects的总大小, 还包含有用户访问的历史信息等等。Access Policy设置了 Bucket的访问权限，例如可以设置哪些用户可以访问，是否具有读写权限等。2） Object在一个Bucket可以存放多个Object,在S3系统中存储的Object是被序 列化的，S3系统并不能区分Object的类型，它可能是一个文本文件或者一 个视频文件。MeataData里面存储的是Object创建时间、大小、文件类型等。 另外只要用户能够访问Object的数据，就能够访问MetaData的权限。S3系统中Object的Identfier有两种表示方法，key和locator。KeyKey在

3、Object被创建的时候由用户给定，若用户未指定由系统分配， 要保证key在桶内部是唯一的，不同的桶可以由相同的key,如：有一个 Bucket 的标识为 0,存储了一个 Object 的 key 为 MyDocument/Email/（注： key可以是string类型或其他类型），那么用户就可以通过下面的地址来 访问 Object：当然不能直接访问，用户还需要提供必要的验证信息，因为 Bucket 设置了访问权限，所以当一个访问到达时，首先有一个认证过程。Locatorlocator和key不同，locator的分配必须是全局唯一的，而不是桶内 唯一。通过locator访问object可以

4、越过认证，所以性能上比key要好（吞 吐率、访问延迟等），但是正因为越过了认证，安全性并不好，所以一般 在传输过程中要对locator进行加密传输。和上面key对应如下是一个 locator 例子：这里 3859c89A208FDB5刖是 object 的 locator,它使一个 128 位 16 进制表示的数。存储系统架构S3的整体架构如下图所示：如上图所示，S3存储架构主要是由keymap+Bitstore作为基本的存储功能，然 后coordinator和NodePicker充当调度功能，然后 replicator实现副本的功能， DFDD(discovery,failure,detec

5、tion daemon )用来检测各个组件的运行状态，webservice platform使用来接收和处理客户端client的请求。卜面是多个数据中心部署:2.1 Web Service Platform用来接收客户端的web service请求，然后将这些请求送给 coordinator0 Web Service Platform是存储系统对外的接口，它提供 REST/SOA类型的API,支持一 些对 bucket 或者 object 的操作。例如 creatBucket、listBucket、deleteBucket 等 API。WebServicePlatform还提供计费功能、认证、

6、访问控制等。另外如果该存储系统限制 object的大小，那么 webserviceplatform还需要对 一些大文件进行分割，将它们分成好多chunck,然后为每个chunck分配一个key, 这些key可以是由原来大文件的key作为每个chunck的前缀，后面加上一些按 字母或数字顺序的字段，例如当然客户端也可以设置是否允许系统进行分片，如果不允许则存储失败。2.2 Coordinator 协调器Coordinator是用来协调webserviceplatform和系统中其他组件的。例如：a） 当 webserviceplatform 有 read object 请求时，coordinat

7、or 首先从 keymap 获取 该object以及object的副本存储位置，然后根据这些位置去相应的bitstoreNode取数据。b）当有write object请求时，coordinator首先从NodePicker获取符合一定 SLA 的节点，然后将object写入到这些节点。c） CreatBucket请求时，创建并存储一个新的 bucket,有时候用户未指定 bucket 标识时它也可以为bucket生成一个key2.3NodePickerNodePicker会根据一定的存储策略来选择节点，如下:Durability Policy时续性）至少N个副本被成功存储，writeobje

8、ct才算成功Area diversity policy（K域多样性）Object被存放在多个区域，增加可靠性Locality policy（本地）降低延迟Load balance policy（JrW 衡）平衡各个存储节点的请求量Space balance policy（加负载均衡）平衡各个存储节点的空间利用率Lowest-cost chain policy在 write object时最小开销上述是一些存储策略，NodePicker会根据用户的SLA来选择不同的存储策略,例如：a）有些用户对可靠性要求不高，则可以减少副本数目；b）有些用户对延迟要求比较高，同时要求可靠性，假设副本数目为5,那

9、么可以选择将3个副本使用locality policy来保证延时，另外2个分别存储在两个 不同的区域来保证可靠性；c）有些用户对延迟的要求比可靠性要低，那么可以选择将2（或1）个副本使用locality policy,另外3（或4）分别存放在三个不同的区域里面。d）当coordinator需要read object时，nodepicker会选择一个离用户比较近的位 置的节点给coordinatoroNodePicker为了完成上面的一些调度任务，需要监视节点的状态，如可用资源大小等，而且考虑到节点的状态时刻在变，所以需要定期进行检测2.4KeymapKeymap是用来存储object（和其副本

10、）的存放位置的。2.5BitstoreBitstore是存储object的最终节点，它的内部结构如下To/From coordinatorBitStore NodeStorage node management controller：对外提供存取数据的 API如put、get、releaseLogical file I/O manager该部分实现虚拟化底层的存储设备或者file system,它用object在存储设备上的偏移量以及文件大小来定位文件，它给每个被存储的object提供一个索引，如下所示：Object index tableObject indexOffsetObject SizeMetadata sizeCRCoffset +offset +object size +metadatasizeObject indexNdataObject indexNmetadataObject indexN +1dataObject indexN +1metadataoffset object sizeLogical