AmazonS3架构分析.docVIP

Amazon S3存储系统结构 Eucalyptus是Amazon AWS的开源实现，总体的架构跟实现都是根据Amazon AWS来设计的，所以Eucalyptus的存储系统部分也不例外，下面是AamzonS3存储系统实现的架构。 存储形式 S3是基于桶(Bucket)的存储系统，它把每个被存储的文件当做一个Object，被存储的Object被放到相应的Bucket中，如下所示： Bucket 用户创建的Bucket的BucketName必须是全局唯一的，该名字可以由用户提供，也可以由系统提供。创建的同时会设置Bucket的一些属性： MetaData：包含创建时间、创建者标识、该Bucket中所有Objects的总大小，还包含有用户访问的历史信息等等。 Access Policy：设置了Bucket的访问权限，例如可以设置哪些用户可以访问，是否具有读写权限等。 Object 在一个Bucket可以存放多个Object，在S3系统中存储的Object是被序列化的，S3系统并不能区分Object的类型，它可能是一个文本文件或者一个视频文件。MeataData里面存储的是Object创建时间、大小、文件类型等。另外只要用户能够访问Object的数据，就能够访问MetaData的权限。 S3系统中Object的Identifier有两种表示方法，key和locator。 Key Key在Object被创建的时候由用户给定，若用户未指定由系统分配，要保证key在桶内部是唯一的，不同的桶可以由相同的key，如：有一个Bucket的标识为050739517，存储了一个Object的key为MyDocument/Email/message.txt(注：key可以是string类型或其他类型)，那么用户就可以通过下面的地址来访问Object： /050739517/MyDocument/Email/message.txt 当然不能直接访问，用户还需要提供必要的验证信息，因为Bucket设置了访问权限，所以当一个访问到达时，首先有一个认证过程。 Locator locator和key不同，locator的分配必须是全局唯一的，而不是桶内唯一。通过locator访问object可以越过认证，所以性能上比key要好(吞吐率、访问延迟等)，但是正因为越过了认证，安全性并不好，所以一般在传输过程中要对locator进行加密传输。和上面key对应如下是一个locator例子： /locator/3859C89A208FDB5A这里3859C89A208FDB5A就是object的locator，它使一个128位16进制表示的数。 存储系统架构 S3的整体架构如下图所示： 如上图所示，S3存储架构主要是由keymap+Bitstore作为基本的存储功能，然后coordinator和NodePicker充当调度功能，然后replicator实现副本的功能，DFDD(discovery, failure,detection daemon )用来检测各个组件的运行状态，web service platform 使用来接收和处理客户端client的请求。 下面是多个数据中心部署： Web Service Platform 用来接收客户端的web service请求，然后将这些请求送给coordinator。Web Service Platform 是存储系统对外的接口，它提供REST/SOAP类型的API，支持一些对bucket或者object的操作。例如creatBucket、listBucket、deleteBucket等API。WebServicePlatform还提供计费功能、认证、访问控制等。 另外如果该存储系统限制object的大小，那么webserviceplatform还需要对一些大文件进行分割，将它们分成好多chunck，然后为每个chunck分配一个key，这些key可以是由原来大文件的key作为每个chunck的前缀，后面加上一些按字母或数字顺序的字段，例如/050739517/MyDocument/Email/message.txt/1 /050739517/MyDocument/Email/message.txt/2 当然客户端也可以设置是否允许系统进行分片，如果不允许则存储失败。 Coordinator 协调器 Coordinator是用来协调webserviceplatform和系统中其他组件的。例如： 当webserviceplatform有read object请求时，coordinator首先从keymap获取该object以及object的副本存储位置，然后根据这些位置去相应的bitstore Node取数据。 当有writ