Amazon EBS是专门为Amazon EC2 虚拟机设计的弹性块存储服务。Amazon EBS可以为Amazon EC2的虚拟机创建卷volumes，Amazon EBS卷类似没有格式化的外部卷设备。卷有设备名称，同时也提供了块设备接口。你可以在Amazon EBS 卷上驻留自己的文件系统，或者直接作为卷设备使用。也就是说EBS就是一个基于集群的完美的“大磁盘”，可以随机读写，较高性能，完美的一致性和高可靠。本来以为这只是幻象，十分不好做。杨公一席话让我茅塞顿开。所以猜测EBS的架构如下，内部人士不要笑话我。
架构
- EBS虚拟磁盘驱动器：EBS客户端构件，和EC2部署在一起，同生共死。作为操作系统的磁盘驱动器存在。作用是管理该磁盘的块,接受磁盘请求。
- 缓冲存储：我猜测，如果要想保证高性能，同时保证数据不丢失，需要使用一个本地的持久化存储作为缓冲和缓存。直接对集群进行大量的细碎的操作，延迟是不可接受的。如果使用长连接，多网卡，可以让延迟变得可以接受，那么这个组件就不是必须的。
- 类S3:类似S3的Key-Value存储。有高可靠，高延时，高吞吐的特点。肯定不是S3，也许也不是Key-value，但是大致是类似的。不可修改和按块存储的特性是相似的。
- 类Mysql:类似Mysql的DB,用来存储块的信息，必须高可靠，容量不比太大，压力也不大。
- Slave:可选组件，Slave会记录磁盘驱动器的每个操作，同步其日志。如果EC2那台机器的缓冲存储损坏，可以使用Slave上面的来恢复最近这段时间没有同步到S3的数据。
存储方式
存储的基本单位是块。每个块由Key和Value组成。块的Key分三部分:diskNo-blockNo-version,Value就是Block的内容。块存储在”S3″中，每个块都是不可以修改的，逻辑上的修改通过增加版本来实现。同时不是每一次修改都必须增加版本的。具体方式下面说。块的大小估计在4M左右，要综合”S3″的性能来决定。
一个“盘”由若干个“块”构成，需要记录每一个”块版本号”，blockNo和块的个数在盘创建的时候就已经决定了。“块版本号”信息持久化存储在Mysql中。
这个架构分两层，S3是底层，负责不断存储“盘”的快照。本地缓冲提供低延迟读写。
实现
下面分几种情况，分别来讨论如何实现。
创建，挂载盘
当创建一个盘的时候，只要在Mysql生成一个新的DiskNo。根据盘的大小和Block的大小，计算出Block数量，在Mysql中初始化元信息，将每个Block的版本标记为0(Block在物理上还不存在)。
然后“磁盘驱动器”挂载他，将Mysql中的源信息，加载到内存中。如果上次非正常关闭，可以通过缓冲存储中的数据，执行恢复操作。因为这个盘不是共享的只有该EC2可以使用。所以挂载后不需要再读Mysql.所以对元数据的操作都发生在内存中，每隔一段时间(比如10分钟)，将元数据增量添加到Mysql。
有一点需要注意的是，如果一个块在元数据中有，这个块的数据可能在本地缓冲也可能在S3上。但是如果在Mysql的元数据中有，S3上必须存在有该块。
读块
根据blockId，可以得之其最近版本，并且是在本地缓冲存储还是在”S3″，直接访问即可。读过的块可以放入缓冲。
写块
写块比较复杂。当发起一个写操作的时候，如果本地不存在或者正在同步，本地会先写入一个临时块，写入成功就返回成功。然后会找到”S3″上的块，下载合并修改。如果本地存在，并且该块不在同步中，就直接修改。
每隔一段时间，系统会建立一个check point，将修改的块增加一个版本号，同步到“S3”中去。这里的同步是异步的。全部完成算完成，不存在中间状态。如果操作系统对一个块修改10次，但这些修改操作在两次同步之间，只增加一个版本，避免重复。
缓冲存储损坏
如果缓冲存储损坏，如果没有Slave。由于S3和Mysql中有上一次的快照信息，所以可以恢复到最近的快照状态。不会出现一致性问题。但Check Point之间的时间间隔可能比较长，如果无法忍受的话，可以建立一个Slave用来记录所有的写操作，但缓冲存储损坏的时候，可以通过Slave上的数据恢复到最近的点。
总结
分布式的虚拟磁盘，可以通过两层存储架构，同时满足严格的一致性和分区要求，也有好的随机读写性能。之所以可以采取两层存储，是因为一块“盘”只能一台机器独享，不要求共享，相当于在可分区的特性上打了个折扣，所以这样应该是没问题的。
亚马逊的测试报告也是写的性能远远大于读性能，和这个架构的特点也是相似的。暂时没有发现什么冲突的地方。当然这个架构只是我的猜想，做不得数的。
好像除了亚马逊，没有其他公司对这种磁盘系统感兴趣，也许是没有必要吧。这样虚拟出来的磁盘性能有限，而且系统层次越多越不稳定。但“云计算”招摇撞骗，大行其道，探索一下也好。
